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

[brmail]

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

Comments

[dibr.livejournal.com]

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

"I asked Intel about this and it turns out that the DRAM on the Intel drive isn't used for user data because of the risk of data loss, instead it is used as memory by the Intel SATA/flash controller for deciding exactly where to write data (I'm assuming for the wear leveling/reliability algorithms). Despite the presence of the external DRAM, both the Intel controller and the JMicron rely on internal buffers to cache accesses to the SSD." [http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403&p=10]

Если я правильно понял, эти буфера - не DRAM а SRAM, и они не очень большие (256к у интела). И я не уверен, что их можно "отключить": при перезаписи одного сектора в блоке, читается в буфер, стирается и пишется заново весь блок, то есть совсем без буфера обойтись не удастся (и вероятность потери данных, в том числе "соседних" секторов в том же блоке, всё равно будет ненулевая).

[brmail]

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

[dibr.livejournal.com]

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

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

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

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