Твердотельные накопители (SSD, Solid-State Drive)

[AMDBulldozer]

оставлять неразмеченную область - это общая рекомендация для всех SSD? Это есть где-то в документации или это личные наработки/опыт пользователей? »

Такие рекомендации по отдельным моделям давали производители. Они полностью совпадают с мнением экспертов в обзорах SSD. Дело в том, что для записи данных требуется наличие пула свободных блоков (обычно размером 512 кБ), которые постепенно расходуются по мере записи. При этом для записи любого, даже самого маленького объема данных, как правило требуется отдельный пустой блок. При изменении данных в каком-либо секторе, пустой блок будет использован (вполне возможно, что не сразу - данные могут быть временно помещены в журнальный блок) в 100% случаев.
Когда пул становится слишком маленьким или когда контроллеру нечего делать, он занимается тем, что объединяет данные разбросанные по всему SSD в блоки данных содержащих непрерывную последовательность логических (512-тибайтных блоков). То есть, из пула свободных блоков выбирается один (допустим, с минимальным значением счетчика записи, чтобы обеспечить более-менее равномерный износ ячеек), в него переносятся данные из других блоков, а те блоки освобождаются и помещаются в пул свободных. Таким образом, лучше всего создавать условия при которых пул свободных блоков мог бы восстанавливаться во время отсутствия дисковой активности. А единственный способ добиться этого - сделать этот самый пул побольше размером.
Это было краткое изложение принципов работы SSD.
Теперь нам будет легче ответить на вопрос, зачем нужно оставлять какое-то количество объема свободным.
Причин минимум четыре.
1. Поскольку пространство на SSD выделяется 512-тикбайтными блоками и любое изменение данных в пределах этого блока требует выделения еще одного 512-тикбайтного блока, то для хранения заданного объема информации фактически требуется заметно больший объем места на SSD.
2. SSD работает быстрее HDD до тех пор, пока у него есть этот самый пул свободных блоков. Если пул исчерпается, скорость записи на SSD сразу снизится в несколько раз и может стать ниже скорости записи на жесткий диск.
3. Чем меньший объем SSD занят данными, тем лучше работает алгоритм распределения записи по разным блокам с целью обеспечения равномерного износа ячеек (wear leveling).
4. Особенностью технологии SSD является неизбежное снижение производительности по мере эксплуатации. Наличие достаточного количества свободного пространства на SSD существенно замедляет этот процесс, вплоть до того, что деградация производительности оказывается в пределах статистической погрешности.

[Sirko9]

легче ответить на вопрос, зачем нужно оставлять какое-то количество объема свободным »
это известно уже давно, мне только не понятно, почему происходит подмена понятий: не размеченная область и не занятое пространство?
И что, создатели драйверов для контроллера нигде не написали про нужду в не размеченной области, а рассчитывали на смекалку юзеров SSD? бред, извиняюсь

[minos66]

Статья: Как свободное место на SSD влияет на его производительность и срок службы | Вадим Стеркин (http://www.outsidethebox.ms/14484/)
Обсуждение статьи в форуме (http://forum.oszone.net/thread-251978.html)

[AMDBulldozer]

это известно уже давно, мне только не понятно, почему происходит подмена понятий: не размеченная область и не занятое пространство?
И что, создатели драйверов для контроллера нигде не написали про нужду в не размеченной области, а рассчитывали на смекалку юзеров SSD? »

1. Нераспределенная область удобнее тем, что она гарантированно не будет занята. И Вы всегда знаете её объем. Объем свободного пространства области, занятой файловой системой определить значительно сложнее.
По очень простой причине. Если Вы удаляете файл, файловая система вычеркивает запись о нем из каталога, в котором он содержится (эта процедура выглядит по-разному в разных ФС) и добавляет блоки, которые были заняты этим файлом к списку свободных. (В операционных системах производства Microsoft блок часто называют "кластером").
Для жесткого диска этого достаточно. Но не для твердотельного накопителя. Для освобождения блоков на SSD система должна выполнить операцию TRIM (если это SATA диск) с каждым из освобождаемых блоков. Если она не сможет этого сделать (допустим, отключилось электропитание), блоки превратятся в "потерянные". Они будут везде отмечаться как свободные, хотя на самом деле заняты.
Это первое. Есть и вторая причина - если распределить весь объем диска под раздел в котором будет создана файловая система, свободного пространства останется меньше, чем в предложенном варианте. Ведь часть этого свободного пространства будет занята метаданными файловой системы. Чем больше размер ФС - тем больше размер метаданных, логично? Конечно, эта величина невелика, но, тем не менее, какой смсыл впустую расходовать дисковое пространство, которое можно сэкономить?
2. Про "создателей драйверов". А что, простите, автор драйвера должен давать рекомендации по использованию этого драйвера в каждом конкретном случае? Может быть Вы забыли, что SSD и HDD управляются одним и тем же драйвером?
(конечно, любой производитель вправе выпустить для своего диска специальную версию драйвера, но мы не об этом сейчас говорим).
Резюме: "создатели драйверов нигде не написали про нужду в не размеченной области" потому, что этот вопрос не в их компетенции. А вот производители SSD об этом писали. Потому что только производитель может сказать какой процент емкости диска он зарезервировал под нужды контроллера.
Вы же встречали SSD емкостью 60 или 120ГБ, верно? Откуда берется такая ёмкость? Это всё те же диски 64 или 128ГБ у которых доступный пользователю диапазон страниц искусственно ограничен, а зарезервированных блоков - увеличен.
Хотя зарезервированный объем есть и у дисков с "круглой" (в двоичном исчислении) ёмкостью.
Давайте посмотрим. 64ГБ это 64,000,000,000 байт. В то же время, количество ячеек в том же диске (в пересчете на SLC) будет 64*2^30=68,719,476,736. То есть даже на таком диске 7.374% объема зарезервировано.
Если тот же диск имеет форматируемую емкость 60ГБ, значит производитель зарезервировал вдвое больше - 14.532% ёмкости.
Теперь понятно, почему авторы драйверов не могут дать никаких рекомендаций? Они не только не знают, какой объем ячеек зарезервирован (это знает только производитель), они даже не в курсе каким именно устройством в данный момент этот драйвер управляет.
Конечно, пользователь может в любой момент получить паспорт диска, но драйверы пишутся так, чтобы они могли управлять любым устройством данного типа. Им просто незачем знать конкретную модель.

[Sirko9]

Может быть Вы забыли, что SSD и HDD управляются одним и тем же драйвером? »
я вообще-то про firmware для контроллера на самом жестком диске
ну и про не размеченную область, получается данные могут располагаться вне файловой системы?

[AMDBulldozer]

ну и про не размеченную область, получается данные могут располагаться вне файловой системы? »

У SSD нет взаимно-однозначного соответствия между номерами блоков файловой системы (допустим, они имеют размер 4кБ) и номерами страниц (тоже 4кБ) накопителя.
Если такое соответствие существовало, механизм wear leveling'а не смог бы работать.
Когда Вы записываете логический блок с каким-то номером на SSD, запись происходит, очень упрощенно говоря, в первый попавшийся свободный 512-тикилобайтный блок, который помечается как занятый. А номер логического блока фактически превращается в атрибут и так же записывается на SSD.
Принцип тот же, что у кэш-памяти процессора. Ведь в одной и той же строке кэш-памяти могут сначала храниться данные из одного диапазона адресов ОЗУ, а потом - совершенно из другого.
Поэтому, когда происходит запись на SSD блоки из нераспределенной области точно так же используются для хранения данных файловой системы.
Возьмем для примера оперативную память. Вы можете запросить ОС выделить Вам участок памяти в каком-то диапазоне логических адресов. Но физические адреса выделенной памяти не будут иметь ничего общего с логическими и могут оказаться разбросаны по всему физическому адресному пространству. Вам кажется, что Вы получили адреса в непрерывном диапазоне, но это только логический диапазон. А в действительности Вам дали несколько фрагментов физических адресов в разных местах.
Или возьмем файловую систему. С точки зрения пользователя файл представляет собой непрерывную последовательность байт. Однако соответствующие различным смещениям в файле блоки могут быть разбросаны по всей файловой системе.

Ну я уж даже не знаю как еще продемонстрировать разницу между логической и физической адресацией. Уже три примера привел...

Поэтому да, данные файловой системы не только могут, но и непременно будут располагаться в нераспределенной области SSD. Она для того и оставляется, чтобы хранить данные, которые Вы записываете в раздел, содержащий файловую систему.

Прошу прощения за повторы и нудное изложение.

[Vadikan]

Нераспределенная область удобнее тем, что она гарантированно не будет занята »
И неудобнее тем, что при необходимости вы не сможете ей воспользоваться моментально. Зачем искусственно ограничивать себя? Контроллеру же все равно, размечена область или нет. Если TRIM есть в ОС, просто поддерживайте свободное пространство на разделе

это известно уже давно, мне только не понятно, почему происходит подмена понятий: не размеченная область и не занятое пространство? »
Потому что "неразмеченное пространство" - это старый гарантированный совет на все случаи жизни.

AMDBulldozer, можно было просто сослаться на статью, чтобы не повторять нудное изложение про гигабайты и круглые цифры в размерах дисков :) Заодно стало бы ясно, в дисках с какими именно контроллерами эти круглые цифры присутствуют.

P.S. В шапке три минуса SSD из четырех явно устарели. Пора обновить.

[ShaddyR]

В шапке три минуса SSD из четырех явно устарели. »
... в частности?

[AMDBulldozer]

AMDBulldozer, можно было просто сослаться на статью, чтобы не повторять нудное изложение про гигабайты и круглые цифры в размерах дисков »

Простите, какую именно статью Вы имеете в виду?
Если Вашу, то я её читал и, прошу меня извинить, но с некоторыми утверждениями в ней не согласен. Хотя, не буду спорить, что статья хорошая, нужная и полезная. Однако, я не люблю ссылаться на публикации, авторы которых в каких-то вопросах придерживаются мнения, которое я считаю ошибочным. Свои собственные взгляды я набросал в серии сообщений в данной ветке ( http://forum.oszone.net/post-2025797-221.html - http://forum.oszone.net/post-2026504-227.html ), но ссылаться на них тем более не было смысла: они писались на скорую руку, по памяти, отличаются ужасной стилистикой и очень эклектичным изложением - многое из того, что хотел, я просто забыл туда добавить. Плюс, насажал кучу ошибок и опечаток, что окончательно сделало текст неудобочитаемым.

[minos66]

В шапке три минуса SSD из четырех явно устарели. Пора обновить. »
... в частности? » Явно два минуса напрашиваются на редактирование:
совместимость. » и ошибки в реализации устройств. »
И вот это По умолчанию на SSD-накопителях с высокой производительностью произвольных чтения, записи и перезаписи будут также отключены технологии Superfetch, ReadyBoost и Рrefetch » не совсем верно. Например у меня на Windows 8 (OC установлена "по умолчанию") и Рrefetch не отключен и Superfetch в одном из svchost постоянно проживает. ReadyBoost действительно отключен.

[Vadikan]

Если Вашу, то я её читал и, прошу меня извинить, но с некоторыми утверждениями в ней не согласен. Хотя, не буду спорить, что статья хорошая, нужная и полезная. Однако, я не люблю ссылаться на публикации, авторы которых в каких-то вопросах придерживаются мнения, которое я считаю ошибочным. Свои собственные взгляды я набросал в серии сообщений в данной ветке ( http://forum.oszone.net/post-2025797-221.html - http://forum.oszone.net/post-2026504-227.html ) »
Да, на мою (http://bit.ly/FreeSpaceSSD). Сказав "А", скажите уж и "Б", тем более что сам автор просит вас указать на ошибочность своего мнения :) Если в статье есть ошибки, надо их исправить, чтобы не вводить людей в заблуждение.

Я прочел ваши взгляды, и навскидку расхождение вижу лишь в вашей рекомендации не выполнять тесты CDM, которые присутствуют в статье.

ShaddyR, в частности устарело:
Обычная (MLC, Multi-level cell, многоуровневые ячейки памяти) флеш-память позволяет записывать данные примерно 10 000 раз, более дорогостоящие виды памяти (SLC, Single-level cell, одноуровневые ячейки памяти) — более 100 000 раз. »
Сейчас MLC 3K и 5K, а новых потребительских дисков с SLC фактически нет.

Большинство имеющихся на сегодняшний день ОС семейства Microsoft Windows не учитывают специфику SSD накопителей, что приводит к дополнительному износу устройств. Например, использование операционными системами механизма свопинга (подкачки) в случае SSD-накопителя уменьшает срок эксплуатации устройства; »
Учитывают, и даже ниже об этом сказано (и я об этом ниже скажу). Приведен один пример, ок, а еще? Да и вообще, информация подается под типичным соусом, намекающим на оптимальность хранения диска в серванте :)

Поскольку технология достаточно новая, методы работы еще не отработаны. Потому первые из реализаций имеют ошибки, очень часто приводящие к различного рода сбоям - начиная от неадекватной работы устройств (медленное чтение\запись, сбои поверхности етс.) и заканчивая полным выходом устройства из строя »
Это вообще бла-бла. Какие "первые из реализаций"?

По умолчанию на SSD-накопителях с высокой производительностью произвольных чтения, записи и перезаписи будут также отключены технологии Superfetch, ReadyBoost и Рrefetch для операций загрузки ОС и программ. Все эти функции были разработаны для традиционных НЖМД, где произвольное чтение может быть узким местом. »
Как заметил выше minos66, Prefetch не отключается. Пруфы для 8 я в блоге приводил (http://www.outsidethebox.ms/14432/#_Toc345870495), а 7 у меня уже нет. Проверьте - методика описана.

[AMDBulldozer]

Сказав "А", скажите уж и "Б", тем более что сам автор просит вас указать на ошибочность своего мнения Если в статье есть ошибки, надо их исправить, чтобы не вводить людей в заблуждение. »

Я приношу глубочайшие извинения. Как выяснилось, я просто перепутал две Ваши статьи. Положения по которым мы с Вами расходимся (я не утверждаю, что я прав) были замечены мной в статье Сколько проживет ваш SSD? (http://www.outsidethebox.ms/14402/). Во-первых, я принципиально не согласен с используемой Вами методикой подсчета ресурса накопителя. Вы исходите из предположения, что механизм выравнивания износа ячеек работает идеально, в то время как мне приходилось видеть SSD, smart которого показывал, что максимальное количество циклов записи в какую-то ячейку в 6 раз превосходило среднее значение счетчика записи.
Следующий момент. Насколько я понимаю принцип работы твердотельных накопителей, деградация ячеек вызывается не столько операцией записи, сколько стирания.
Если взять Ваш пример с блоками "X" и "Y", то получается, что запись четырех страниц (считайте 16 кБ) влечет за собой операцию стирания всего блока (512кБ). Записали 4 страницы, а износ увеличился у 128-ми.
Кстати, я не совсем понял, что означают наименования страниц со штрихом? Это измененные страницы A-D? Тогда почему в блоке "Y" они находятся не на месте страниц A-D (первые 4 страницы), а на совершенно других местах?
Это возможно только в том случае, если блок на диске является журнальным. Однако операция объединения служит именно для того, чтобы собрать страницы из нескольких (как правило) блоков в блок данных. Именно для того, чтобы освободить место в таблице журнальных блоков.
Конечно, возможно, что Вы описывали гипотетический диск, выполняющий отображение блоков по алгоритму DFTL и, следовательно, не имеющий ограничения на число журнальных блоков. Тем не менее, насколько я понимаю, реальные SSD в большинстве используют гибридные алгоритмы и, значит, операция "merging" у них должна выглядеть несколько иначе - страницы A'-D' после объединения должны занять место на котором были страницы A-D.
Еще одна причина расхождения наших с Вами взглядов заключается в Вашем утверждении (это уже из комментария к предыдущей статье): "Дефрагментация SSD диску не нужна. Файлы могут фрагментироваться, но контроллер сам данные перемещает." Я как раз уверен в обратном, поскольку копирование всех файлов с SSD диска на промежуточный носитель, очистка SSD командой TRIM и копирование файлов обратно устраняют фрагментацию блоков SSD и, как показывает практика, обычно повышают скорость его работы.

P.S. Я еще раз приношу извинения за то, что поднял этот вопрос. Прошу отнестись с пониманием. У меня есть какие-то собственные взгляды на многие вопросы связанные с компьютерной техникой и программным обеспечением. Нередко они в каких-то деталях, очень часто несущественных, расходятся с мнением другого человека.
Но, даже если бы они не расходились, в большинстве случаев я предпочитаю излагать на форуме именно собственные взгляды, а не ссылаться на мнение авторитетов.

[Vadikan]

AMDBulldozer, спасибо за подробный ответ. На самом деле, я предлагал сослаться на конкретное объяснение о "гигабайтах", которое с вашим не расходилось. Если вы предпочитаете каждый раз объяснять это своими словами, это ваш выбор.

Проблема только в подаче материала, извините уж за критику. Если бы вы смогли нормально оформить свои посты в статью (с подзаголовками, нормальной разбивкой на абзацы и т.д.), пользы от материала было бы намного больше. Мы бы с удовольствием разместили это на OSZone - готов помочь в работе.

А так, в принципе, неважно, в какой из моих статей "ошибки", если они действительно таковыми являются.

Во-первых, я принципиально не согласен с используемой Вами методикой подсчета ресурса накопителя. Вы исходите из предположения, что механизм выравнивания износа ячеек работает идеально, в то время как мне приходилось видеть SSD, smart которого показывал, что максимальное количество циклов записи в какую-то ячейку в 6 раз превосходило среднее значение счетчика записи. »
Идеальной и подходящей ко всем накопителям методики подсчета ресурса не существует :) Это просто грубая прикидка. У вас есть какая-то своя методика?

Да и SMART - тоже не истина в последней инстанции. Я видел где-то скриншоты SMART с нормально работающих дисков Intel, сделанные спустя полгода после достижения нулевого ресурса по данным SMART. То есть в данном случае SMART отражает не реальный ресурс NAND, а некие заданные производителем параметры.

Насколько я понимаю принцип работы твердотельных накопителей, деградация ячеек вызывается не столько операцией записи, сколько стирания. Если взять Ваш пример с блоками "X" и "Y",»
Верно. Запись производится в ячейки, а стираются блоки. Именно стирание и знаменует цикл перезаписи для блока. Но какая разница, по большому-то счету? Можно считать, что операции записи приводят к стиранию блоков, поскольку их число ограничено.

Пример же нельзя воспринимать буквально. Я пишу для обычных людей, а не для железных гиков, объясняя общую концепцию на достаточном для понимания уровне и не перегружая материал техническими деталями. В этом случае упрощение в подаче материала неизбежно. Вы же измеряете его штангенциркулем и пытаетесь из него определить какие-то конкретные алгоритмы.

Еще одна причина расхождения наших с Вами взглядов заключается в Вашем утверждении (это уже из комментария к предыдущей статье): "Дефрагментация SSD диску не нужна. Файлы могут фрагментироваться, но контроллер сам данные перемещает." »
В комментариях я подбираю слова не так аккуратно, как в записях, но опять же, вы воспринимаете их буквально и вне контекста. "Дефрагментация SSD диску не нужна" я писал в ответ на этот комментарий (http://www.outsidethebox.ms/14432/#comment-11658)
Я со всем согласен, но на счет дефрагментации… ее делал только один раз после установки системы и всех программ, Windows в 2 раза быстрее стал загружаться, проверено
Наверное, мне следовало сказать, что "Не надо выполнять дефрагментацию SSD дефрагментаторами для жестких дисков”, но я думал, что из контекста это понятно.

Я как раз уверен в обратном, поскольку копирование всех файлов с SSD диска на промежуточный носитель, очистка SSD командой TRIM и копирование файлов обратно устраняют фрагментацию блоков SSD и, как показывает практика, обычно повышают скорость его работы.
Я и не спорю с этим утверждением. Но вы же не будете это делать после установки ОС и программ^^ :) Кроме того, далеко не всегда такая процедура необходима. Зачастую достаточно только TRIM, что достигается простым форматированием раздела даже средствами Windows. У меня нет тестовой лаборатории и кучи накопителей, но на одном из своих дисков я это проверил – результаты теста вернулись к тем, что были на момент покупки.

Проблема же присуща контроллерам SandForce, когда диск забивается сжатыми данными, с которыми сжимающий все контроллер толком «не знает» что делать. Вот в этом случае TRIM может быть недостаточно…

Кстати, о производительности. Как я понял, вы не рекомендовали выполнять тесты CDM и подобные им. А как вы посоветуете определять производительность накопителя? Откуда пользователю знать, понизилась производительность SSD или нет? И как понять, восстановилась она или нет, после TRIM и последовательного копирования?

И еще один момент. Вы пишете:
Любые тесты осуществляющие случайную запись на диск, либо использование программ, осуществляющих такую запись (к примеру торрент-клиентов) быстро и эффективно приведет к необратимому снижению производительности работы твердотельного диска. »
Использовать SSD для "мелких случайных операций" - оптимальный способ получить неустранимое падение производительности и ускоренный износ. Особенно в несколько потоков - тогда фрагментация (всех видов) гарантирована! »
Наиболее характерная активность ОС и программ в типичных домашних задачах - это как раз запись маленьких блоков. Как-нибудь на досуге я попробую собрать конкретные данные, но не удивлюсь, если она составит половину от всех операций чтения/записи. И что, теперь ОС и программы на SSD не ставить? Прокомментируйте, плиз.

[AMDBulldozer]

Наиболее характерная активность ОС и программ в типичных домашних задачах - это как раз запись маленьких блоков (4k). Как-нибудь на досуге я попробую собрать конкретные данные, но не удивлюсь, если она составит половину от всех операций чтения/записи. И что, теперь ОС и программы на SSD не ставить? Прокомментируйте, плиз. »

Для начала дам возможно более краткий ответ на Ваш вопрос относительно операций записи: к большинству программ и сервисов операционной системы мой совет отношения не имеет. Поскольку, независимо от размера записываемых данных, они обычно локализованы в ограниченном диапазоне LBA. Поэтому они займут значительно меньшее количество блоков данных на SSD - многие страницы попадут при записи в один и тот же блок. В то же время, запись данных того же размера в случайные места на SSD сначала приведет к исчерпанию запаса свободных журнальных блоков, а потом, в ходе преобразования журнальных блоков в блоки данных, потребует (с некоторым преувеличением) записи каждой страницы в отдельный блок данных. Таким образом, случайная запись приводит к быстрому исчерпанию пула свободных блоков, причем освободить занятые блоки при помощи операции объединения оказывается уже невозможно.
Я мог бы привести еще целый ряд аргументов в пользу своей точки зрения, но ограничусь этим одним. Чтобы у уважаемых участников форума не складывалось впечатления, что мои утверждения ничем не аргументированы.

Однако меня больше волнует другой вопрос. Еще раз прошу прощения, но имеет ли смысл сейчас углубляться в технические детали? Я уже говорил и готов повторить, что считаю Ваши статьи очень нужными и полезными для большинства пользователей. Потому что те вопросы, по которым мы в данный момент пытаемся дискутировать, я уверен, не нужны и не интересны 99% пользователей. На мой взгляд, им достаточно иметь самое общее представление о работе устройства.

Может быть мы с Вами сойдемся на том, что я извинюсь, сниму свои замечания и мы закроем данную тему? Ведь, откровенно говоря, она и возникла-то в результате того, что я неправильно себя повел. Когда Вы спросили, почему я не дал ссылку на Вашу статью (действительно хорошую статью из которой я почерпнул для себя информацию о положении дел с конкретными моделями), мне не нужно было вдаваться в подробные объяснения.

Искренне сожалею, что превратил ответ на простой вопрос в длительную переписку.

С уважением...

[Vadikan]

AMDBulldozer, гм... мне кажется, у вас сложилось впечатление, что меня "зацепили" ваши комментарии относительно моей статьи, и "в отместку" я решил цепляться к вашим словам.

На самом деле, что вы глубже меня разбираетесь в подноготной работы SSD с технической точки зрения. В этом контексте, вы находите что-то странное в том, что я задаю вам вопросы? :) Вы же сами написали несколько "программных" постов в этой теме. Неужели вы думали, что никто не попросит вас уточнить какие-то моменты?

[minos66]

Наиболее характерная активность ОС и программ в типичных домашних задачах - это как раз запись маленьких блоков. » А кэширование? На диск запись идет идет из Modifed оперативки? Ну еще из Standy в случае с файлом подкачки. Наверное ОС не по страничке скидывает из оперативки на диск. Вот я на форуме сижу. Файлы на запись небольшие, но и не по 4К.
http://s018.radikal.ru/i517/1302/60/123e4c1e0c45.jpg (http://www.radikal.ru)

[Vadikan]

minos66, я ж говорю, надо собрать данные и посмотреть. В ФП должно писаться большими блоками.

[AMDBulldozer]

Я бы оценил средний размер блока данных передаваемых в файл подкачки где-нибудь в 64кБ. Это не более, чем личное мнение - ссылок представить не могу.

[Vadikan]

AMDBulldozer, по данным разработчиков Windows:
блоки записи в Pagefile.sys довольно велики, 62% из них больше или равны 128 Kб и 45% – почти точно 1 Mб
Я уже цитировал (http://www.outsidethebox.ms/14432/#_Toc345870499) их телеметрию в блоге.

[AMDBulldozer]

Значит я ошибался. Благодарю за информацию. Хотя вообще-то имел в виду Linux - с Windows я, как уже отмечал, к сожалению не знаком.