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