Ещё раз о btrfs и nilfs2

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

Противоречивые результаты измерений быстродействия, полученные для btrfs и nilfs2 , не давали мне покоя. И потому, вернувшись после некоторого перерыва в Xubuntu, точнее, в её тестовую версию (9.10), я был рад обнаружить там ядро 2.6.31-rc2, собранное с модульной поддержкой обеих этих файловых систем.

Инструментарий для nilfs2, в виде пакета nilfs2-tools, также легко нашёлся в репозитории. С инструментарием для btrfs было похуже – в наличии имелся лишь пакет btrfs-tools-0.18-4, тогда как специально для разрабатываемого ядра существовали уже исходники версии 0.19. Благо, собирать их, как при первом знакомстве с btrfs , не пришлось: необходимый deb-пакет обнаружился в репозитории Debian unstable. Каковой был немедленно скачан и установлен посредством

sudo dpkg -i btrfs-tools_0.19-2_amd64.deb

После этого оставалось только перейти к измерениям быстродействия. Которые, как и ранее, сводились к замерам скорости копирования набора flac-файлов, iso-образа CD, большого avi-файла, а также копирования и удаления дерева портежей Gentoo (подробности).

На этот раз под тестовые развлечения у меня было припасено два первичных раздела по 8 Гбайт, лежащие в конце второго, 500-гигабайтного диска, тогда как система располагалась на первом, 160-гигабайтном.

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

Однако, прежде чем рассматривать её содержание, необходимо сказать несколько слов о том, как проходили измерения – ход их дал несколько непредвиденных, но интересных наблюдений.

Относительно измерений на btrfs говорить особенно нечего – она была смонтирована с опцией relatime (ныне стандартной в большинстве пользовательских ситуаций), и в ходе измерений никаких неожиданностей не произошло.

А вот с nilfs2 они начались сразу. Мало того, что она не монтируется от имени пользователя – даже при наличии соотвествующей записи в /etc/fstab, и требует явного указания типа файловой системы (о чём уже говорилось в предыдущей заметке ). В добавок к этому оказалось, что команда mount не воспринимает для nilfs опцию relatime – в прошлый раз я просто банально забыл это проверить. По этому поводу я решил провести измерения для nilfs дважды – на смонтированной по умолчанию и смонтированной с опцией noatime.

И тут обнаружилась ещё одна вещь, в результате которой каждую серию измерений с nilfs2 пришлось разбить на две части. В обсуждении предыдущей заметки на Джуйке был поднят вопрос:

Правильно я понял, что при удалении файла ничего на самом деле не удаляется, лишь записывается лог о новом состоянии.

Тогда я не был готов к ответу, а сейчас могу сказать определённо: да, действительно, удаление файлов не приводит к высвобождению дискового пространства, по крайней мере, немедленному. И показания команды df для занятого объёма не только не уменьшаются после удаления, но даже, хотя и немного, увеличиваются – за счёт «разбухания» журнала, надо полагать. И это при том, что никаких снапшотов файловой системы я ещё не делал – хотя в планах это и было.

Разумеется, то, что команда df для любых Unix-подобных файловых систем может не отражать реальное соотношение занятого и свободного дискового пространства, известно с давних времён. Однако в nilfs2 этот эффект не исчезал не только после отмонтирования её и повторного монтирования, но даже после перезагрузки,

Следствием описанного явления было то, что раздел, несущий nilfs2, у меня заполнился очень быстро, не дав возможности в один приём выполнить копирование очень большого avi-файла – не смотря на удаление всех остальных составляющих тестового массива, свободного места на нём не прибавлялось.

Надо полагать, что когда-нибудь блоки, занятые удалёнными файлами, будут освобождены физически – иначе достаточное количество операций записи и удаления в состоянии заполнить абсолютно любой объем дискового пространства. Однако когда и при каких обстоятельствах это происходит – для меня пока остаётся не ясным. Нужно будет покопаться в первоисточнике, то есть прочесть наконец официальную документацию на nilfs2.

А пока единственным способом высвобождения места на разделе под nilfs2 было пересоздание файловой системы – благо, процедура эта выполняется практически мгновенно. Как, впрочем, и для файловой системы btrfs. После чего мне удалось закончить все измерения, результаты которых и сведены в таблице.

Таблица

Операция Копирование Удаление
Объект Flac Iso Avi Portage Portage
Btrfs 00:11 00:21 01:50 00:28 00:09
NILFS2 00:21 00:35 01:34 00:44 00:02
NILFS2, noatime 00:09 00:14 02:37 00:15 00:02

Как мы помним, в прошлый раз  при копировании средних, больших и очень больших файлов btrfs (смонтированная в режиме relatime) оказалась быстрее, нежели nilfs2 (которая тогда монтировалась с параметрами по умолчанию), иногда вдвое и более. Ныне при тех же условиях btrfs значительно опередила nilfs на копировании средних и большого файла, чуть-чуть отстав от неё (в пределах ошибки эксперимента) на копировании файла очень большого:

nilfs-btrfs01.gif

nilfs-btrfs02.gif

nilfs-btrfs03.gif

Задание опции noatime для btrfs дало чуть ли не обратную картину на приведённых выше диаграммах. При копировании серии средних и большого файла nilfs2 оказалась, хоть и не сильно, но быстрее btrfs. Зато при копировании авишки результат «поднялся» чуть не вдвое (в затраченном времени). Хотя, казалось бы, как раз в случае операций над очень большим единичным файлом запрет обновления времени доступа сильно сказаться не мог даже в положительную сторону, не говоря уже об отрицательной.

На операциях с большим количеством очень маленьких файлов nilfs в прошлый раз опережала btrfs – не сильно, но уверенно при копировании, и ураганно – при удалении. Ныне же при копировании дерева портежей nilfs в умолчальном состоянии существенно отстала от btrfs, с лихвой наверстав своё при запрете обновления atime:

nilfs-btrfs04.gif

На удалении дерева портежей файловой системой nlfs2 впервые был вдвое перекрыт рекорд быстродействия при этой операции, уже много лет незыблемо принадлежавший ReiserFS – причём в обоих режимах монтирования. Ну а btrfs в очередной раз показала, что удаление мелкофайлового агрегата – совсем не её конёк:

nilfs-btrfs05.gif

От окончательных выводов пока воздержусь – очередные испытания дали достаточно противоречивые результаты (особенно в сравнении с предыдущими). Разве что стали мучительно ясны два момента:

  1. в сравнении быстродействия файловых систем нового поколения следует ждать их окончательной стабилизации, и
  2. методика измерения быстродействия файловых операций окончательно изжила себя, и надо придумывать новую.

Надесь, что к тому моменту, как свершиться первое, я и со вторым что-нибудь придумаю.

Ещё раз о btrfs и nilfs2: 3 комментария

  1. Знаменательный номер статьи, юниксовый такой ]:-)
    <p>Цитата из http://torrents.ru/forum/viewtopic.php?t=1453138

    «Файловая система Nilfs2 действительно резвая за счет отложенной записи, но ее сборщик мусора создает слишком много операций чтения записи на SSD.
    Алексей, что скажете на это?

  2. По поводу методики тестированния, как насчет такой программки — bonnie++?

Обсуждение закрыто.