13 521
правка
Изменения
м
* Хранение карт отображения ниже уровня ФС приводит к дополнительным накладным расходам — тратится часть места на устройстве и используется дополнительная оперативная память. Частично это решается большим размером блока, но большой размер блока ведёт к большим накладным расходам на хранение мелких файлов и не поддерживается почти ни одной Linux ФС.
Нет описания правки
== Идея ==
<sub>
'''Идея:''' реализовать простой FTL, пригодный к использованию поверх «тупого» флешечного, в виде драйвера на уровне ОС (модуля Linux). Назвать, например, SFTL. Смысл в том, чтобы не тащить лог-структурированность на уровень файловой системы, как это делается сейчас в JFFS2/UBIFS/LogFS/NILFS/F2FS, а, аналогично SSD’шкам, реализовать это в виде отдельного уровня, по сути, превращающего любую файловую систему в лог-структурированную, и кардинального ускоряющего случайную запись.
Плюсы такой идеи:</sub>
* Главный плюс — реализация ПРОСТА. Засчёт отсутствия необходимости писать код и утилиты ФС. А то, блин, '''ни для одной''' (!!!) из вышеперечисленных ФС, в том числе и для наиболее свежей F2FS, например, нет fsck! Типа они все такие лог-структурированные и сбое-устойчивые. Хотя для F2FS обещают, что fsck когда-то будет.
* Поверх транслированного устройства можно использовать любую обычную файловую систему. Или даже не файловую систему, а, например, raw tablespace для СУБД. Хотя это может потребовать дополнительных фич — например, барьеров.
Минусы идеи:
* Главный минус — дублирование кода аллокатора блоков между FTL и файловой системой, и двойной объём работы. Ведь карты распределения блоков УЖЕ есть у файловой системы в виде информации о том, какие блоки каким файлам принадлежат, а при наличии FTL карты дублируются, что приводит к лишним накладным расходам — и месту на устройстве, и занятой оперативной памяти, и лишней работе, которую должен делать процессор. То есть, в общем, все эти накладные расходы всегда есть и в SSD’шках — но там они выполняются на отдельном процессоре и работе основной системы не мешают.
* Это, в некотором смысле, «велосипедик», частично повторяющий, например, функционал самсунговской F2FS. Частично повторяет и функционал других лог-структурированных ФС, но их можно не рассматривать — они сделаны исключительно под MTD и на блочных девайсах не работают.
* Аналогично SSD, очень желательно реализовать TRIM и очень желательно, чтобы ФС, гоняемая поверх SFTL, его поддерживала. Хотя это, возможно, и не проблема вовсе — многие ФС в Linux, в том числе ext4, xfs и даже VFAT, его поддерживают, а что ещё нужно джентльмену?
* Сложнее реализовать прозрачное сжатие — оно требует, чтобы при выделении блоков ФС понимала, сколько на устройстве реально осталось свободного места. С другой стороны, если код ФС запатчить - запатчить — в принципе, можно реализовать и сжатие.
== Типичная скорость работы флешек ==