Изменения

Простой FTL для флешек

1901 байт добавлено, 11:37, 25 мая 2013
м
Нет описания правки
* Скорость случайной записи '''очень''' низка и, независимо от размера блока, составляет обычно 2-3 операции записи в секунду, так как в реальности почти каждая операция ведёт к перезаписи целого Erase Unit’а. При размере блока в 512 байт скорость случайной записи составит всего лишь 1-2 килобайта в секунду!
* Наилучшая скорость и чтения, и последовательной записи достигается при размере блока &ge; <WRITE UNIT>. Скорость чтения (любого — последовательного, случайного) блоками размера <WRITE UNIT> составляет обычно мегабайты в секунду — 6-12 Мб/с.
 
Отличия флешек от MTD с точки зрения нашего FTL:
* На MTD можно с одинаковой скоростью писать в любой стёртый сектор (что, разумеется, удобнее). На флешках так делать нельзя, а можно держать лишь максимум LIMIT (~6) активных регионов.
* Зато при записи на флешки можно не обращать внимания на Erase Unit’ы — этим занимается её внутренний FTL. Если конкретно:
** Можно очищать блоки мелкими порциями, в то время, как на MTD нужно очищать и стирать Erase Unit целиком. Размер сегмента, не кратный размеру Erase Unit (как у нас — 128.5 Кб), использовать при этом можно — просто потребуется при очистке затрагивать ещё и пограничные сегменты.
** Можно не делать динамического Wear-Leveling’а (то есть WL перезаписываемых данных) на уровне блоков стирания — флешечный FTL делает это сам. Однако, флешки обычно не двигают статические данные, поэтому может потребоваться Static Wear Leveling. Кроме того, отдельные кластеры внутри всех блоков стирания должны записываться равномерно — нельзя, например, всегда записывать 1-ый сектор каждого Erase Unit’а в 10 раз чаще остальных.
== Структура хранения ==
Во-первых, обеспечить возможность очистки сегмента в худшем случае, то есть, даже если осталось всего лишь N сегментов, в каждом из которых свободен всего 1 кластер. Для этого N-1 сегмент должен быть зарезервирован.
Во-вторых, также нужен фоновый сборщик мусора. В-третьих, можно тоже пытаться разделять сектора по частоте их перезаписи. Очень простым способом — с помощью K-средних разбить всю флешку на K «регионов», и стараться писать сектора с соответствующим количеством перезаписи в соответствующий регион. K нужно выбирать меньшим или равным лимиту открытых на запись блоков во флешке.
При записи:
* Если свободных сегментов нет ни в родном, ни в соседних регионах — значит, кончилось место и надо переходить к экстренной очистке. Экстренную очистку, опять-таки, пытаемся сначала сделать в «родном» сегменте, а потом в соседних.
* Сначала пробуем найти наиболее легко очищаемую последовательность N сегментов и переместить из них данные в последовательность N-1 зарезервированных сегментов. После такой очистки мы получим связный регион, в котором N-1 сегмент станет зарезервированным, а в оставшийся 1 можно будет что-нибудь записать. Очищать пробуем сначала в родном регионе, потом — в соседних.
* Если таких последовательностей уже не осталось — это значит, что места, во-первых, осталось довольно мало (теоретический максимум худшего случая — 1/N, но в среднем — гораздо меньше), а во-вторых, место оно сильно фрагментировано. Тогда очистку нужно делать по-другому — берём брать данные из сегмента, следующего за свободными зарезервированными, и распределяем распределять по отдельным свободным кластерам в разбросанных по всему диску сегментах.
Такое разбиение флеш-памяти на регионы, хоть и способствует ускорению записи, всё равно непригодно для MTD (голой NAND памяти), потому что не осуществляет Wear-Leveling, а наоборот — больше изнашивает одни части памяти и меньше — другие.
 
В-третьих, нужен и фоновый сборщик мусора, хотя бы с жадной стратегией.
== Дополнительная идея: сжатие ==