13 521
правка
Изменения
м
(2) Решить относительно легко. Тупейший вариант — это, не обращая внимания Вообще забить на фрагментацию, и всегда писать в первый доступный свободный кластеркластер — не решение. Производительность записи при этом будет падать приблизительно на количество пропущенных при записи (занятых) кластеров внутри каждого Erase Unit’а. То есть цена пропуска кластера примерно равна цене его записи, так как большую часть времени записи занимает стирание. Проблема, на самом деле, общая для всех лог-структурированных ФС. Решают её по-разному. В первую очередь почти во всех реализациях есть фоновый процесс — «сборщик мусора». Из других идей: в F2FS предпринята попытка разделять при записи «холодные», «средние» и «горячие» блоки. А что делать с фрагментацией нам?
Более сложный вариант решения: Предлагается зарезервировать часть сегментов (не меньше N-1 сегментов ) и следить, чтобы кроме зарезервированных всегда был как минимум один свободный сегмент. При записи, когда число свободных сегментов будет становится равным N-1, искать и дефрагментировать ближайшие частично свободные сегментыочищать наиболее пустую (то есть, наиболее легко очищаемую) последовательность N сегментов. Резерв нужен для того, чтобы даже в худшем случае дефрагментация удалась. Худший случай — это сборка свободного сегмента из N сегментов, в каждом из которых свободен только 1 кластер — чтобы вместить данные из этих N сегментов, очевидно, нужен N-1 свободный. Цена перемещения данных равна времени их чтения + записи.
С (1) — проблемой фрагментации в целомКроме того, общей для всех лог-структурированных ФС — ситуация посложнеепонадобится и фоновый сборщик мусора. Методы борьбы с нейОн, в принципе, придуманыможет делать почти ту же операцию дефрагментации в фоновом режиме. F2FSПлюс можно попробовать сделать так, например, (а) использует фоновый сборщик мусора (б) пытается разделять запись «холодные», «средние» и «горячие» блоки и (в) пытается чуть умнее обычного выбирать кластер при сборке мусорачтобы он старался очищать последовательные области.
Нет описания правки
SSD содержат «умный» FTL; USB-флешки и карты памяти содержат «тупой» FTL. Засчёт «тупости» последнего случайная запись сводится к полной перезаписи отдельных Erase Unit’ов, и поэтому происходит ОЧЕНЬ медленно — обычно 2-3 операции в секунду.
== Идея ==
'''Идея:''' реализовать простой FTL, пригодный к использованию поверх «тупого» флешечного, в виде драйвера на уровне ОС (модуля Linux). Назвать, например, SFTL. Смысл в том, чтобы не тащить лог-структурированность на уровень файловой системы, как это делается сейчас в JFFS2/UBIFS/LogFS/NILFS/F2FS, а, аналогично SSD’шкам, реализовать это в виде отдельного уровня, по сути, превращающего любую файловую систему в лог-структурированную, и кардинального ускоряющего случайную запись.
Плюсы такой идеи:
* Главный плюс — реализация ПРОСТА. Засчёт* Реализация становится сильно проще засчёт отсутствия необходимости писать код и утилиты ФС. А то, блин, '''ни для одной''' (!!!) из выше перечисленных ФС, в том числе и для наиболее свежей F2FS, например, нет fsck!Хотя для F2FS обещают, что в будущем он появится.
* Поверх транслированного устройства можно использовать любую обычную файловую систему.
* В принципе, с небольшими изменениями можно использовать почти одну и ту же реализацию для MTD и для USB-флешек.
Минусы идеи:
* В Это, в некотором смысле, это «велосипедик» — «велосипедик», частично повторяетповторяющий, например, функционал самсунговской F2FS. Частично повторяет и функционал других лог-структурированных ФС, но их можно не рассматривать — они сделаны исключительно под MTD и на блочных девайсах не работают.
* Хранение карт отображения ниже уровня ФС приводит к дополнительным накладным расходам — тратится часть места на устройстве и используется дополнительная оперативная память. Частично это решается большим размером блока, но большой размер блока ведёт к большим накладным расходам на хранение мелких файлов и не поддерживается почти ни одной Linux ФС.
* Очень желательно реализовать TRIM и очень желательно, чтобы ФС, гоняемая поверх SFTL, его поддерживала. Хотя это, возможно, и не проблема вовсе — многие ФС в Linux, в том числе ext4, xfs и даже VFAT, его поддерживают, а что ещё нужно джентльмену?
* Последовательная запись блоками по <WRITE UNIT> Кб или большими примерно в 2 раза медленнее чтения такими же блоками. Типичный WRITE UNIT = 32 Кб.
* Последовательная запись блоками, меньшими <WRITE UNIT> примерно в 4 раза медленнее чтения такими же блоками.
* Erase Unit составляет обычно 1/2/4 Мб, а может составлять и больше. Естественно, команды ERASE у USB-флешек нет, но размер блока стирания легко определить, варьируя размер блока при случайной записи.
* Скорость случайной записи '''очень''' низка и, независимо от размера блока, составляет обычно 2-3 операции записи в секунду, так как в реальности почти каждая операция ведёт к перезаписи целого Erase Unit’а. При размере блока в 512 байт скорость случайной записи составит всего лишь 1-2 килобайта в секунду!
* Наилучшая скорость чтения/последовательной записи достигается при размере блока ≥ <WRITE UNIT>. Скорость чтения (любого — последовательного, случайного) блоками размера <WRITE UNIT> составляет обычно мегабайты в секунду — 6-12 Мб/с.
# В какой-то момент может оказаться, что сегментов, свободных целиком, нет вообще, хотя свободного места при этом вполне хватает.
== Дополнительная идея: сжатие ==