архив
Ещё раз о btrfs и nilfs2
2009-07-29
Противоречивые результаты измерений быстродействия, полученные для 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 пришлось разбить на две части. В обсуждении предыдущей заметки на Джуйке Ostin'ом был поднят вопрос:
Правильно я понял, что при удалении файла ничего на самом деле не удаляется, лишь записывается лог о новом состоянии?
Тогда я не был готов к ответу, а сейчас могу сказать определённо: да, действительно, удаление файлов не приводит к высвобождению дискового пространства, по крайней мере, немедленному. И показания команды df для занятого объема не только не уменьшаются после удаления, но даже, хотя и немного, увеличиваются – за счёт «разбухания» журнала, надо полагать. И это при том, что никаких снапшотов файловой системы я ещё не делал – хотя в планах это и было.
Разумеется, то, что команда df для любых Unix-подобных файловых систем может не отражать реальное соотношение занятого и свободного дискового пространства, известно с давних времён. Однако в nilfs2 этот эффект не исчезал не только после отмонтирования её и повторного монтирования, но даже после перезагрузки,
Следствием описанного явления было то, что раздел, несущий btrfs, у меня заполнился очень быстро, не дав возможности в один приём выполнить копирование очень большого 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 на копировании средних и большого файла, чуть-чуть отстав от неё (в пределах ошибки эксперимента) на копировании файла очень большого:
Задание опции noatime для btrfs дало чуть ли не обратную картину на приведённых выше диаграммах. При копировании серии средних и большого файла nilfs2 оказалась, хоть и не сильно, но быстрее btrfs. Зато при копировании авишки результат «поднялся» чуть не вдвое (в затраченном времени). Хотя, казалось бы, как раз в случае операций над очень большим единичным файлом запрет обновления времени доступа сильно сказаться не мог даже в положительную сторону, не говоря уже об отрицательной.
На операциях с большим количеством очень маленьких файлов nilfs в прошлый раз опережала btrfs – не сильно, но уверенно при копировании, и ураганно – при удалении. Ныне же при копировании дерева портежей nilfs в умолчальном состоянии существенно отстала от btrfs, с лихвой наверстав своё при запрете обновления atime:
На удалении дерева портежей файловой системой nlfs2 впервые был вдвое перекрыт рекорд быстродействия при этой операции, уже много лет незыблемо принадлежавший ReiserFS – причём в обоих режимах монтирования. Ну а btrfs в очередной раз показала, что удаление мелкофайлового агрегата – совсем не её конёк:
От окончательных выводов пока воздержусь – очередные испытания дали достаточно противоречивые результаты (особенно в сравнении с предыдущими). Разве что стали мучительно ясны два момента:
- в сравнении быстродействия файловых систем нового поколения следует ждать их окончательной стабилизации, и
- методика измерения быстродействия файловых операций окончательно изжила себя, и надо придумывать новую.