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