Франкенштейн: восстание JFFS2 или Немного о файловых системах для raw flash

После успешного запуска ядра Linux на нашем франкенштейне (модуль Colibri PXA320 c 128Mb RAM и 1Gb  NAND FLASH) нужно было двигаться дальше — собрать bootstrap и загрузиться хотя бы в консоль.

В отличие от нашего предыдущего проекта, в Colibri стоит NAND флэш, а не NOR. NAND получает все большее и большее распространение в силу своей дешевизны и при этом большей вмесимости чем NOR (небольшое сравнение NOR  и NAND можно посмотреть тут).

Процессор Marvell PXA320 со своим встроенным NAND контроллером и сама микросхема NAND флэш поддерживаются основной веткой ядра. В общем, ничто не предвещало беды и было решено пойти  по накатанной — развернуть на NAND JFFS2 (Journaling Flash File System version 2) с корневой файловой системой.

Но тут вдруг обнаружилось что старый добрый JFFS2  мало того что полторы минуты сканирует NAND, дак еще и работать отказывается напрочь =(. Попробовав различные версии ядра, различные конфиги ядра и способы разворачивания файловой системы на флэш (монтирование и разворачивание из архива, запись образа напрямую в NAND) работоспособности я так и не добился. Ну да не JFFS-ом единым подумал я и стал смотреть в сторону других файловых систем.

Первым под руку попался проект YAFFS (Yet Another Flash File System) — пропатчил ядро (в основной ветки поддержки YAFFS нет, но это не беда — можно скачать патч с сайта проэкта и запатчить им ядро), собрал, запустил — сканирование всего раздела (чуть меньше гига) заняло минуту с небольшим, при последующих загрузках все происходило быстро, без задержек. Но при первом же аварийном завершении — опять минуту с небольшим. В остальном, вполне работоспособная вещь.

Вторым была выбрана UBIFS (Unsorted Block Image File System) — файловая система от создателей JFFS2. Перелопатив тонны описаний от разработчиков обнаружил интересную вещь — UBIFS состоит из двух частей — UBI (Unsorted Block Image) и UBIFS. UBI очень похож на LVM (Logical Volume Manager) — тоже поддерживает создание логических томов на одном физическом разделе. Причем  в роли файловой системы поверх UBI можно запустить тот же JFFS2, как утверждают разработчкики. А можно загрузить FTL (Flash Translations Layer) и получить обычное блочное устройство, на которое хоть EXT3 можно натянуть. При этом такие вещи, как журналирование и слежение за равномерным износом NAND будет выполнять UBI.

Я поставил поверх UBI файловою систему UBIFS. Разработчики обещали быстро и надежно, да и сравнительные тесты показывали тоже самое. Первый запуск — присоединение тома занимает около 10 секунд, монтирование происходит моментально, без задержек. Особенность UBI — присоединение тома занимает на гиговом разделе (том 900Мб. Почему не весь раздел — об этом далее) всегда занимает 10 секунд. С одной стороны, много. Но с другой, если работа была завершена аварийно, присоединение тома займет те же 10 секунд, но монтироваться система будет чуть дольше. Но с JFFS2/YAFFS все равно не сравнимо. Как и JFFS2, UBIFS  поддерживает сжатие on the fly, что уже не может не радовать.

Почему том не занимает весь раздел? Потому что UBI резервирует часть свободного места: если какой либо блок будет помечен как плохой то вместо него будет использоваться блок из свободного места. По умолчанию UBI резервирует 1% для этого, но это можно изменить в конфигурации ядра.

Cравнение различных файловых систем для raw flash — тут.

Почему в качестве файловой системы не была взята привычная ext2/ext3/raiserfs? А все потому, что эти системы рассчитаны на работу с блочным устройством, т.е. между самой памятью и ядром есть еще некая реализация FTL внутри устройства. NAND/NOR же таких продвинутых штук не имеют, да и не надо им это. По этому для них и используются такие хитрые файловые системы.

Для тех кто хочет помучать UBI и UBIFS , или кто хочет более детально разобраться:

  1. http://www.linux-mtd.infradead.org/faq/ubi.html
  2. http://www.linux-mtd.infradead.org/doc/ubi.html

1 комментарий

  1. mps:

    Привет! 10с — это круто:) Пропатчили OpenOCD — тоже круто!:)