[Vadikan]

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

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

Я прочел ваши взгляды, и навскидку расхождение вижу лишь в вашей рекомендации не выполнять тесты 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 я в блоге приводил, а 7 у меня уже нет. Проверьте - методика описана.

[AMDBulldozer]

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

Я приношу глубочайшие извинения. Как выяснилось, я просто перепутал две Ваши статьи. Положения по которым мы с Вами расходимся (я не утверждаю, что я прав) были замечены мной в статье Сколько проживет ваш SSD?. Во-первых, я принципиально не согласен с используемой Вами методикой подсчета ресурса накопителя. Вы исходите из предположения, что механизм выравнивания износа ячеек работает идеально, в то время как мне приходилось видеть 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 диску не нужна" я писал в ответ на этот комментарий

Я со всем согласен, но на счет дефрагментации… ее делал только один раз после установки системы и всех программ, 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К.

[Vadikan]

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

[AMDBulldozer]

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

[Vadikan]

AMDBulldozer, по данным разработчиков Windows:

блоки записи в Pagefile.sys довольно велики, 62% из них больше или равны 128 Kб и 45% – почти точно 1 Mб

Я уже цитировал их телеметрию в блоге.

[AMDBulldozer]

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