NILFS2: ещё одна файловая система нового поколения

Алексей Федорчук

🕛 18.07.2009, 11:13

Пока широкие народные массы обсуждали достоинства и недостатки файловых систем нового поколения для Linux - ext4 и btrfs, - в ядро Linux версии 2.6.30 без шума и пыли была включена поддержка файловой системы NILFS2. Штатно, хотя и в качестве экспериментальной опции. В опубликованном сравнительном тестировании она показала весьма приличные результаты на фоне своих вышепоименованных товарок. Это вызвало желание пощупать её руками, а поскольку пацан сказал - пацан сделал, желание это было осуществлено при первой же возможности. К чему меня подтолкнуло вот это обсуждение на Джуйке .

Однако сначала надо сказать несколько слов о том, что же это такое - NILFS2, и чем она примечательна. Ведь разговоров о ней почти не было - во всяком случае, гораздо меньше, нежели в свое время о Reiser4 или, позднее, про ext4 и btrfs. Тем более, на русском языке.

Цифра в названии этой файловой системы заставляет предположить, что существует (или существовала) и NILFS просто. И это действительно так - причем существует она достаточно давно: первый релиз этой системы увидел свет в октябре 2005 года, то есть за год до обнародования ext4 и за два года до публикации btrfs. Будучи разработана специальной Киберпространственной лабораторией (CyberSpace Laboratories) компании Nippon Telephone and Telegraph, она вскоре стала распространяться под лицензией GPL, а с конца 2008 года пошли разговоры о грядущем включении её второй версии (то есть уже собственно NILFS2) в ядро Linux. Что и осуществилось, как уже было сказано, с выходом версии оного за номером 2.6.30.

Аббревиатура NILFS расшифровывается как New Implementation of a Log-Structured File System, что можно перевести примерно как Новая Реализация Файловой Системы с Журнальной Структурой.

NILFS2 принадлежит к классу журналируемых файловых систем, и именно с журналированием связана первая её особенность. В отличие от всех прочих собратьев, журнал файловых операций в ней ведётся подобно обычным лог-файлам: то есть данные в журнале не перезаписываются, а лишь дополняются. Что, конечно, увеличивает расход дискового пространства - но кого это волнует при нынешних объёмах винчестеров?

А вот оборотная сторона медали гораздо существенней: лог-подобное журналирование не только способствует поддержанию целостности файловой системы при глобальном крахе, но и снижает риск потери данных в такой ситуации. Ведь, вопреки легенде, само по себе журналирование файловой системы вовсе не направлено на сохранность пользовательских данных, а в первую голову на сохранение собственной целостности.

В какой-то мере можно провести аналогию между лог-журналированием NILFS2 и режимом полного журналирования в ext3. Однако, в отличие от последнего, оно не ведёт к снижению быстродействия. Напротив, исходя из общих соображений, можно ожидать его повышения. И несколько позже мы увидим, что ожидания эти оказываются не напрасными.

Далее, вторая фирменная особенность NILFS2 - возможность создания снапшотов. Что само по себе тоже не уникально: эту операцию можно выполнить посредством механизма LVM, она поддерживается в UFS2, а в чрезвычайно развитом виде является штатной функцией ZFS, логическим завершением чего выступает знаменитый Time Slider из OpenSolaris (в общих чертах описанный здесь ).

Однако и здесь NILFS2 идёт своим путём. Во-первых, она даёт возможность непрерывной "видеозаписи" состояния файловой системы без прерывания или замедления прочих файловых операций, что способствует быстродействию. Во-вторых, при этом не осуществляется полного бэкапа данных, как в Time Slider - нет, сохраняются, причем совершенно отдельно, в самостоятельных блоках, лишь изменения их состояния. И в-третьих, непрерывно сохраняемые контрольные точки - своего рода "стоп-кадры" в нашей "видеозаписи" состояния файловой системы, - могут быть в любой момент примонтированы (в режиме read only) параллельно основной файловой системе, на предмет внесения в неё коррекции ошибок, вне зависимости от того, были они обусловлены крахом системы или неправильными действиями пользователя.

Дополнительный плюс NILFS2 получает при использовании SSD-накопителей, несмотря на свой небольшой объем и большую цену, получающих всё большее распространение. Ибо, как бы ни совершенствовались их контроллеры, перезапись данных для устройств такого типа не показана им как с точки зрения быстродействия, так и с позиций сохранности самих накопителей.

В общем, все указанные особенности (а подробнее с ними можно ознакомиться в официальной документации проекта - правда, увы, не просто на английском, но ещё и в pdf-форамате) выглядят очень привлекательно. Остаётся только на собственном опыте убедиться, что "не врут мальчишки", и что всё описанное действительно так. Особенно в сравнении с товарками-соперницами - а ими, напомню, выступают дамы весьма серьёзные: ext4 и btrfs.

Как я уже говорил, с точки зрения конечного пользователя пригодность файловой системы к употреблению во внутрь (собственного системного блока) определяется тремя факторами:
1. надёжностью; 2. быстродействием; 3. простотой использования.

Причём для разных пользователей и разных задач приоритеты этих факторов также могут быть разными.

Надёжность файловой системы проверяется временем её использования в реальных, в том числе и не штатных, условиях, поэтому ничего определённого на эту тему я сказать пока не могу. Кроме как то, что банальное выключение питания она переживает безболезненно - но так реагируют и все прочие современные файловые системы, за исключением ext2. Вопросы быстродействия я оставлю на закуску - как завершение настоящей заметки. А пока обращусь к условиям использования.

Первое условие - наличие соответствующего ядра, то есть не младше 2.6.30. Я использовал RFRemix 11 с ядром и зависимыми пакетами, установленным из "сыромятной" ветки - то есть 2.6.31-0.42.rc2.fc12.x86_64.

Затем следует проверить, включена ли поддержка NILFS. В моём случае конструкция

$ less /boot/config-2.6.31-0.42.rc2.fc12.x86_64 | grep NILFS

показала, что она присутствует в виде модуля:

CONFIG_NILFS2_FS=m

Как и поддержка необходимого для неё вычисления 32-битных контрольных сумм:

$ less /boot/config-2.6.31-0.42.rc2.fc12.x86_64 | grep CRC32
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_CRC32C_INTEL=m
CONFIG_CRC32=y
CONFIG_LIBCRC32C=m

Далее требуется инструментарий для работы с соответствующей файловой системой - пакет nilfs-utils. В официальных репозиториях и Fedora, и RFRemix таковой отсутутствует. Но его можно найти на сайте проекта для 64-битной или 32-битной версии). Попытки подключить его в качестве репозитория в настоящий момент успехом не увенчаются (на сайте дано объяснение причин, но я в него не вникал). Не получилось у меня и установить скачанный пакет посредством yum localinstall - пришлось действовать лобовым методом:

su -c 'rmp -ihv nilfs-utils-2.0.13-1.x86_64.rpm

что завершилось благополучно.

Отступление: на том же сайте доступны также бинарные сборки для CentOS, Debian, OpenSuse и Ubuntu. А на SourceForge можно найти ссылку на AUR-пакет для Archlinux. Исходники же для самостоятельной сборки в более иных дистрибутивах можно скачать отсюда .

Теперь остаётся действовать по обычаю, исконно заведённому: обычным способом, получив права администратора, например, с помощью fdisk/cfdisk/parted, создать раздел (или пожертвовать существующим), на нём - нашу новую файловую систему:

# mkfs.nilfs2 /dev/sd?#

и попробовать её примонтировать сначала от имени root'а же:

# mount -t nilfs2 /dev/sdb2 /mnt

Обращаю внимание, что указание типа файловой системы в явной форме обязательно - иначе последует сообщение об ошибке, mount из пакета e2fsprogs сам собой волшебным образом NILFS2 пока не распознаёт.

Если всё предыдущее было сделано правильно, монтирование пройдёт успешно, хотя нас честно предупредят, что формат этой файловой системы может измениться, и потому ей пока не стоит доверять свои критически важные данные:

mount.nilfs2: WARNING! - The NILFS on-disk format may change at any time.
mount.nilfs2: WARNING! - Do not place critical data on a NILFS filesystem.

Что же, я пока этого делать и не собирался - а хотел лишь посмотреть на NILFS2 и, в частности, оценить её быстродействие в сравнении с соперницами - ext4 и btrfs. Для чего выполнить своеобычный набор тестов.

Так что я проделал все указанные выше процедуры, пожертвовав разделом, на котором недавно проводил эксперименты с btrfs версии 0.19 (для равенства условий). Теперь же желательно было обеспечить монтирование от имени обычного пользователя - не мерять же скорость обычных файловых операций с правами администратора. Для этого по опять таки давно заведённому порядку я внес в файл /etc/fstab строку

/dev/sdb2 /home/alv/test nilfs2 noauto,user,relatime 0 0

И для пробы попробовал выполнить монтирование с правами обычного пользователя:

mount test/

На что получил следующий ответ:

mount.nilfs2: mount by non-root user is not supported yet

Ждать, пока монтирование non-root'ом будет supported я, разумеется, не стал. А примонтировал раздел с NILFS2 именем администратора всё в тот же каталог /home/alv/test, установкой соответствующих атрибутов обеспечил доступ к нему обычного пользователя и выполнил все файловые манипуляции, последний раз описанные здесь. Результаты замеров скорости их выполнения, в сравнении с ближайшими подругами-врагинями (btrfs v. 0.19, ext4 для Linux, ZFS для FreeBSD), приведены в таблице.

Таблица
Операция Копирование Удаление
Объект Музыка Portage Avi Iso Portage
NILFS2 00:09 00:44 01:32 00:19 00:09
Btrfs 00:05 00:52 01:13 00:08 00:26
Ext4 00:10 00:15 01:44 00:19 00:04
ZFS 00:12 00:29 02:30 00:21 00:16
tmpfs 00:01 00:04 - 00:00 00:01
В целом можно констатировать, что во всех проведённых тестах быстродейтсвие NILFS на уровне остальных файловых систем нынешнего поколения. Так, при копировании массива средних файлов

файла большого

и очень большого

она показывает несколько лучшие результаты, нежели ext4 и ZFS, хотя и существенно отстаёт от btrfs последнего разлива - абсолютного рекордсмена по этим трём показателям.

При копировании большого количества мелких файлов NILFS2, напротив, существенно уступает ext4 и ZFS, несколько опережая btrfs:

В удалении же дерева портежей, где btrfs показала откровенно провальные результаты, NILFS2 выглядит вполне достойно, лишь немного отставая от чемпиона - ext4:

При интерпретации результатов следует учитывать, что лобовое копирование любых данных - не та операция, на которой NILFS2 способна продемонстрировать все преимущества своего подхода. Более показательным была бы запись изменённого массива данных, однако каким образом это можно реализовать - я пока не придумал.

И ещё: хотя различия между скоростью выполнения отдельных операций для разных файловых систем на графиках выглядят весьма впечатляющими, следует помнить, что в абсолютных величинах речь идёт об очень незначительных отрезках времени, в большинстве случаев почти не заметных при реальной работе. Иными словами, быстродействие современных файловых систем приближается к теоретически возможному пределу, каковым можно считать файловые операции в tmpfs (последняя колонка в таблице, данные для очень большого файла отсутствуют, так как конфигурация моей системы предполагает для /tmp масимальный объем в 2 Гбайт).

!!!То есть быстродействие перестаёт играть решающий фактор!!! при выборе файловых систем - оно определяется уже скорее "железом", нежели их устройством. А потому на первый план выступают два других фактора - надёжность и удобство. Если с точки зрения надёжности, как я уже говорил, ничего определённого пока сказать нельзя (да и трудно ожидать стопроцентной надёжности от файловых систем с экспериментальным статусом), то вот с точки зрения удобства NILFS2 явно хромает - за счёт невозможности монтирования её без прав администратора. Разумеется, возможное изменение формата файловой системы удобства ей не добавляет. Впрочем, последнее можно поставить в упрёк и btrfs, последняя версия которой не может быть получена конвертацией из предыдущей. Хотя существенный плюс btrfs (и, соответственно, минус - NILFS2) - возможность конвертации в неё распространённых файловых систем ext, ext3, а по последним сведениям, правда, мной ещё не проверенным - также и ext4.

В общем, можно констатировать, что время для повсеместного применения NILFS2 (как, впрочем, и btrfs) ещё не настало. Так, обе эти системы я предполагаю использовать пока в качестве хранилища для софта, скачиваемого из Сети, то есть исключительно для легко восстановимых данных.