В том-то и дело, что при загрузке винды большой разницы и нет (я её загружаю раз в 2-3 недели). А вот например прикол вроде того, что SP2 на MS Office поставился за 40 секунд ты даже с винтами на 15K rpm не увидишь. Что неудивительно, ведь в чтении/записи мелких блоков с большой глубиной очереди SSD в 100+ раз быстрее самого быстрого HDD. Если верить Crystal Disk Mark, то для моего HDD - 1.3/1.3 Мб/сек чтение/запись, а для SSD - 440/250 Мб/сек.

И много обычных винтов у вас прожили хотя бы 10 лет? И сколько из них актуальны на текущий момент? Имхо, более чем на 5 лет вперед заглядывать нет смысла. С большой вероятностью "старые" системы хранения станут неактуальными. А на SSD все производители дают три года гарантии (а Intel на большинство даёт 5 лет).

Тут такое дело, что если своп на 16 Гб, то это не значит, что туда будет записываться в 16 раз больше данных, чем при свопе в 1 Гб. Поэтому, имхо, уменьшать своп имеет смысл только для освобождения места на диске. Не стоит забывать, что мы все уже давно не на Win 98 сидим, у которой использование свопа было больным местом.

К тому же да, SSD на 64 Гб за несколько лет вполне можно перезаписать 50-100 раз. Если же у вас будет винт на 256 Гб, то вряд ли вы его за то же время перезапишете даже 20-30 раз (при том же сценарии использования). Скорее всего будут цифры поменьше...

Да и дороговизна SSD уже совсем не та. OCZ Agility 4 128 Гб стоит 3100 руб в улмарте (не самый дешевый магазин). Этого легко хватит для винды + программ + пары любимых игр... Да что там - Crucial M4 256 Gb можно за 6400 руб в приличном магазине купить.

Потребуется больше - поставим больше.

Контроллер для уменьшения износа равномерно использует для записи только свободную область. Или кто-то сомневается? Если производитель "гарантирует 2083 полных цикла перезаписи", то при свободном объёме в 120Гб можно записать 120Гб * 2083 = 250Тб (в статье 1Тб=1000Гб). Если диск системный, и на нем установлено много программ и игр, то эти данные, в основном, не изменяемые: исполняемые файлы и библиотеки. Но у многих на этом же диске кеш браузера, файл подкачки, восстановление системы, сохранения игр и т.д., то есть - изменяемые данные. Эти данные не могут записываться на занятое место, это очевидно, значит будут равномерно размазываться по свободным 120Гб. Допустим (не знаю каким боком) в день вы записываете 240Гб (как в примере статьи), то в день свободная область будет полностью перезаписываться 2 раза, тогда при 2083 циклах перезаписи у вас останется 2083/2=1041,5 дней или 1041,5/365=2,85года, как ни странно - это в 2 раза меньше чем если перезаписывать те же 240Гб в день на полностью пустой диск.

Vityok777
Еще не учли 3 момента для полноты картины:
1) Модификация 1 байта потянет за собой перезапись всего блока (сколько там размер блока флэш - 64к?)
2) Еще есть износ служебной области, повреждения которой более фатальны для данных, чем повреждения пользовательской
3) Есть еще понятие "дефект кристалла" и "утечка заряда". Дефективная ячейка может к примеру терять заряд за несколько месяцев (сам лично столкнулся с этим в м/сх биоса в далеком 2000-м). А естественная утечка заряда зависит от кол-ва циклов перезаписи, чем больше циклов - тем быстрее теряется заряд

NiTr0
все верно, но Intel примерно учла эти параметры, когда при заявленных характеристиках чипа 3000 циклов, указала усреднённые 2083 (правда, в эти же 2083 цикла включены "запасные" гигабайты и без них сбойные блоки появились бы после 1500-1700 циклов).
Просто некоторым не понравилось мое замечание, что при уменьшении свободного места, пропорционально уменьшается время жизни.

Как может уменьшатся то чего нет? У ССД нет такого понятия как время наработки, это же не НЖД.

Bezenchuck
Допустим, что указано допустимое количество циклов перезаписи - 3000. Это значит, что один бит в микросхеме памяти гарантировано выдержит минимум 3000 циклов стирания - записи (так работает флеш память: чтобы записать всего один бит, нужно сначала вычитать блок ~64Кб, потом стереть блок, потом изменить в блоке необходимый бит, затем записать блок обратно). Контроллер следит за тем чтобы блоки использовались равномерно, то есть обратно блок будет записан в новую ячейку памяти, которая меньше всего изношена по мнению контроллера (из-за ошибок в прошивке, контроллер может ошибаться и писать в самую изношенную). Так вот, рано или поздно, но каждый из блоков всей доступной памяти отработает положенные ему 3000+ цикла, и тогда каждый блок станет потенциально сбойным, никто не сможет гарантировать, что следующая запись не окажется для этого блока последней (флеш память обычно перестаёт записываться и стираться, в блоке сохраняется последнее записанное значение). Если контроллер записал данные в блок, а потом проверил и получил ошибку, то такой блок помечается сбойным, маскируется, а данные пишутся в другой блок, сначала из внутреннего резерва. И когда кончится резерв, то начнет уменьшаться физический размер диска. Вот когда размер диска вдруг уменьшится на пару гиг, вот тогда и наступает конец диску. Это не полный отказ, данные можно ещё читать, но лучше этот диск уже не использовать.
И чем меньше на диске свободного места, куда можно записывать изменяемые данные, тем быстрее начнет уменьшаться место на диске.
Да, я знаю, что есть алгоритмы, которые при простое диска начинают перемещать неизменяемые данные, которые "засиделись" в неиспользуемой памяти в более используемую, но это не сильно увеличивает ресурс некоторых блоков.

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

Добавлено спустя 7 минут 18 секунд:


Ну вот я прям не знаю, то Вы говорите, что ресурс будет заметно меньше заявленного, то сами рассказываете, как оно будет выглядеть. Но как показала практика - износ у SSD наступает много позже, некоторые ячейки отрабатывают и пятикратный ресурс. Правда со временем диск действительно терял в объеме и работал гораздо медленнее. Но все-равно, что при полном стирании/записи, что при заполнении на 50% и стирании/записи оставшихся 50%, что при стирании/записи 75% объема (при свободных оставшихся 25%) результаты были выше заявленного. Получается, что ячейки ДОЛЖНЫ отрабатывать не менее Х циклов до того, как они начнут выходить из строя, но это не значит, что они НАЧНУТ выходить из строя как только достигнут Х циклов - начнет выходить из строя часть ячеек при Х циклов, другая при 2Х циклов, некоторые и при 10Х циклов. Учитывая "скрытый от глаз" резерв - получаем действительно достаточно долгий ресурс SSD. Да и я сомневаюсь, что кто-то будет в сутки перепахивать 120 гектар данных...

Добавлено спустя 1 минуту 42 секунды:


Имелось в виду не время наработки на отказ, а именно время активной работы ССД. Которое напрямую зависит от количества циклов. Да и у любого устройства в принципе есть MTBF, просто не всегда и не везде указывают. С другой стороны, MTBF это полная хрень.

Дефекты явно не учла Ибо невозможно их учесть, и вылазят они в процессе эксплуатации.


Бред. Данные записываются прекрасно, и могут даже читаться после этого в течение некоторого времени, только через, скажем, месяц некоторые битики уплывут, и вместо ценных данных получите мусор.


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

Я сомневаюсь. Почему не используются "резервы"?


Это проблема ссд записать правильно, а системе все равно куда оно пишется и как.


Смарт ссд информацию по данной области выдает?


Не увеличивают что разве ресурс служебной области. Полагаю и контроллер допускает разброс по кол-ву записей к примеру меняет блоки когда разница достигает 5 или 10 перезаписей.


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

Был у нас в институте интересный такой предмет... Названия сейчас никак не вспомню. Некоторое ответвление от теории вероятности и статистики, но используемое в реальных условиях. Так вот, все дефекты предсказуемы и учитываются, имея мало-мальски известную статистику отказов мы можем предположить (и заложить в расчет) вероятность отказа, его последствия и меры, которые можно принять для предотвращения/уменьшения вероятности отказа и для того, чтобы урон был минимален и последствия устранимы в кратчайший срок и с наименьшими усилиями.



Действительно, а вдруг? Мы же не можем посмотреть, как и какие ячейки используются в данный момент.



Если точнее - проблема контроллера. И не только куда и как оно запишется, а как еще с этим потом работать так, чтобы обеспечивать приемлемое быстродействие + больший ресурс.



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



Чуть выше была высказана мысль, что такая изношенная ячейка будет быстрее терять заряд. И если в нормальной ячейке данные без потерь могут храниться десятилетиями, то в изношенной ячейке может так случиться, что за полгода данные могут испортиться. И вот если ССД работает долгое время нормально, а потом полгода в простое - попытка прочесть такие ячейки закончится большим обломом с потерей данных - их уже просто невозможно будет перезаписать в другое место - подпорчены будут сильно.

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

А теперь внимааааааааааааааательно смотрим на вот этот фрагмент из этой фразы:



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

Это ведомо только производителю - как реализован транслятор служебки (или, если точнее, поиск актуальной копии транслятора - в служебке тоже присутствует ротация секторов).
Я бы вообще на смарт не особо полагался.


Любая флэш-память имеет экспоненциальную зависимость времени хранения от кол-ва циклов записи. Для большинства ячеек макс. кол-во циклов - это кол-во циклов, после которого срок сохранности данных снижается до заявленого (если память не подводит). Но есть и особые ячейки, с дефектами. Которые ничем не отличаются от остальных - кроме того факта, что заряд утекает быстрее.
Кстати, может быть именно отсюда растут ноги у волшебных алгоритмов, позволяющих увеличить ресурс ячеек...


Ну знаете вы, что у купленного вами винчестера среднее время наработки на отказ - 300 000 часов (в пределах гарантийного срока). Это никоим образом не помешает винчестеру взять и осыпаться через пару месяцев эксплуатации. Ибо статистика неприменима к единичному экземпляру. А вот для парка из 1000 устройств - эта цифирь уже будет иметь хоть какое-то практическое применение, исходя из нее примерно каждые 300 часов один из дисков будет уходить на покой...

Я уже говорил, что MTBF - это бред сивой кобылы. Берем 1000 дисков, гоняем их 1000 часов к ряду, считаем, сколько из них вышло из строя. Получим 3 мертвых диска на 1 миллион часов работы, или среднее время наработки на отказ в районе 300 000 часов. Если же гонять 100 дисков по 10000 часов на тот же миллион придется больше вышедших из строя. Или наоборот, если брать 10000 дисков и 100 часов работы - так как вероятность выхода из строя в первые 100-120 часов обычно выше (проявляется заводской дефект), так что все это - абстракция.



Тут даже дело не в том, сколько и с какой периодичностью будет выходить из строя, а в том, как бороться с такими проблемами и минимизировать потери при отказе БЕЗ заметных затрат (в данном случае - без удорожания устройства). То есть найти оптимальное решение. Ведь можно сделать супер-пупер надежный ССД просто продублировав ВСЕ его компоненты и устроив RAID-1 изначально. Сколько это будет стоить? Ведь кому надо, тот сам решит, делать RAID-0 ли ему, или RAID-1, или RAID-10. Производителя же интересует именно оптимальное соотношение цена/качество/быстродействие, так как 90% покупателей будут выбирать именно по этому критерию.

Добавлено спустя 10 минут 34 секунды:


Использую SMART только для определения нескольких RAW значений. Например, 2/3 полетевших в известном направлении дисков имели статус в смарте GOOD на ЯВНО зашкаливающее количество ошибок, перенесенных секторов, сбоев головок и т.п. По смарту проще на глаз по RAW значениям определить, пора уже менять диск или еще потерпит, хотя и тут не обходится без сюрпризов - в последний раз на работе начал сбоить (терять данные) жесткий. Выполнил проверку, диск перенес из опасной зоны все данные, отрапортовал, что все почти ОК и что он готов к работе. Взглянув на зашкаливающие в смарте ошибки чтения и переназначенные сектора я подумал, что еще несколько дней оно протянет, а потом я скину на новый диск все важное и разберу диск, чтобы достать из него магнитики, ня! Но на следующий день диск сказал "я не хочу читать данные, я хочу, что б ты за@%$лся" и превратил в кашу весь загрузочный сектор и таблицу разделов. Итог - 3е суток на выковыривание чудом уцелевших данных и Cucial M4 в качестве нового системного диска, + 2 диска для бэкапа ) А SMART так и показывал на 50% мертвом диске статус GOOD.

Я в этом сомневаюсь. Что абсолютно точно - старые контроллеры (3-5 лет назад) работали примерно по такому принципу (хотя и там были механизмы выравнивания износа), поэтому на SSD через некоторое время ярко проявлялся эффект старения, выраженный в резком снижении производительности (очень наслышан о такой беде в контроллерах Marvell). Грубо говоря без использования Trim (WinXP, например) через пару-тройку часов прогонки тестов скорость записи на чистый (по мнению OS) накопитель падает до 15-20 Мб/сек.

Современные системы корпоративного класса честно обеспечивают положенный ресурс по объему записи, вне зависимости от объема регулярно занятого места. А ведь если следовать вашей логике, то 3/4 постоянно занятого места должно снижать ресурс накопителя по объему записи в 4 раза. Домашние SSD тоже к этому подбираются, потому что менять пользователям по гарантии диски никто не хочет. И проблема того, что забитый на 95% системный диск "исчерпал" ресурс через 3 месяца - проблема производителя.

SSD уже давно и успешно применяются в корпоративном сегменте, и считаются значительно более надежными.