CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
18.08.2017

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Заметки :: Файловые системы

Ещё раз о btrfs и nilfs2

http://alv.me/

Противоречивые результаты измерений быстродействия, полученные для 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 на копировании средних и большого файла, чуть-чуть отстав от неё (в пределах ошибки эксперимента) на копировании файла очень большого:

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. методика измерения быстродействия файловых операций окончательно изжила себя, и надо придумывать новую.
Надеюсь, что к тому моменту, как свершиться первое, я и со вторым что-нибудь придумаю.



Комментарии

аноним, Mon Nov 23 07:46:38 2009:
куда им всем до ntfs?
Юрий, Mon Nov 23 05:57:38 2009:
на счёт 3 версии - я бы поспорил. ext4 или reiser4 - это ещё ладно. но reiser3 - это пипец!!
Bren74, Thu Aug 6 23:27:34 2009:
To аноним, среда, 29 июля 2009 г. 10:47:03:
-----------
Те же мысли - но в отношении ext3.
Фридрих, Thu Aug 6 23:12:09 2009:
2 аноним:

Я, собственно, так и делаю :)
аноним, Wed Jul 29 10:47:03 2009:
честно говоря, чем больше читаю заметки автора файловых системах, то больше укрепляюсь во мнении, что на десктопе стоит выбрать реизер3 и голову не морочить)

Комментарии заморожены.

Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds