Как работает SSD

[brmail]

Не столько для оповещения публики, сколько для памяти - потом ссылаться если что. Подробная-подробная статья с картинками и обьяснениями как работают твердотельные накопители, как оно там внутри реализовано, почему есть проблемы с количеством перезаписей, и как с ней борются.
Действительно подробно разжевано. На примере Intel X25-M SSD, на английском
http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403&p=1
Кстати, для тех кому подробно и на иностранном лень - идея быстрого диска реализованного Интелом не только в том, чтоб обьеденить несколько кусков флеша в обин большой диск как это делается в RAID, но и в том, что у диска есть достаточно большой кусок динамической памяти, буфер область, в которую он быстро пишет-читает, и по идее если питание вырубается то все что в ней еше не сохранено на диск (не успела, не шмогла) просто пропадает. Кстати буфер этот можно отключить что сильно снизит скорость его работы.

Comments

[brmail]

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

[dibr.livejournal.com]

> Ксати любопытна ситуация, когда на диске мало свободного места. Ну к примеру 16-гиг всего диск и на нем уже стоит винда, офис итд.

Диск не знает и знать не может, свободно место или занято, этим FS занимается, а она несколько "выше" в иерархии. Тут автор статьи "путается в показаниях" и путает других.

Проблема не совсем в свободном месте (место с точки зрения физического диска *всегда* занято, свободны только резервные блоки), а в наличии большого количества мест, перезапись которых естественным образом не происходит (та же винда/офис, они ведь сами себя не переписывают и по диску не бегают). Нет перезаписи блока - нет ситуации, при которой блок можно перенести. Нет переноса блока на новое место - нет соответственно и переноса *другого* блока на место этого, и соответственно "непереносимые" блоки не изнашиваются, а остальные изнашиваются сильнее.
Решения два:
1) так и оставить: если блок не перезаписывается естественным образом, то и пусть его. Wear leveling делать только среди перезаписываемых блоков, ну и среди резервных блоков. Достоинства - простота реализации, "винда и офис" гарантированно никуда не денутся. Недостаток - плохой wear leveling. С другой стороны - сколько там процентов той винды от объема диска? А данные пусть иногда, но переписываются.
2) иногда принудительно переносить "неизменяемые" блоки на новое место. Достаточно делать это довольно редко - "неизменяемый" блок попадёт на относительно изношенное место и может лежать там и дальше, а его место автоматически попадёт в "ротацию" изменяемых блоков и начнёт изнашиваться. Достоинства - идеальный wear leveling, недостатки - сложнее, немного (несущественно) медленнее, есть небольшие шансы убить даже "неперезаписываемую" информацию.
Что реально реализовано в контроллерах - как обычно, никто не знает, а производители держат тайну :-)

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