Инфо Файловые системы современного Linux'а: последнее тестирование

Эта статья посвящена тестированию быстродействия файловых систем, ныне используемых в Linux'е в качестве нативных, то есть тех, на которых эта ОС может жить и загружаться. Может возникнуть вопрос — почему это тестирование последнее? Спешу разочаровать — Linux отнюдь не собирается прекращать своё существование, да и в моих ближайших планах переход в лучший мир не значится. И потому — маленькое пояснение.


В качестве нативных файловых систем для ныне действующего Linux'а можно рассматривать:

1. ext2fs — исконную (и, значит, самую "родную") из файловых систем для этой ОС;
2. ext3fs — её журналируемую разновидность, продолжающую генеральную линию развития предшественницы при практически полной с ней совместимости;
3. reiserfs — ещё одну журналируемую файловую систему, разработанную Хансом Рейзером специально для Linux, но с "чистого листа";
4. JFS — эпоним всех журналируемых файловых систем, созданную в IBM первоначально для их собственного варианта UNIX'а, AIX, позднее портированную на OS/2 и Linux;
5. XFS — также изначально чуждую Linux'у (разработана SGI для IRIX), но удачно на него портированную.

Разумеется, список поддерживаемых Linux'ом файловых систем этим не исчерпывается: на уровне обмена данными (то есть чтения и, хотя и далеко не всегда, записи) под этой операционкой можно общаться если не со всеми, то с подавляющим большинством файловых систем, изобретенных человечеством. Однако сам по себе Linux "живёт" только на перечисленных файловых системах.

С одной оговоркой: в принципе эту операционку можно установить на раздел, несущий FAT, и даже запускать с него. Одно время такая возможность, как особо выдающаяся "фича", включалась в инсталляторы некоторых дистрибутивов, претендующих на особенную дружбу с пользователем. Однако потом эта идея, как явно нездоровая, была заброшена.

Так что по-настоящему "родными" для Linux'а можно считать только те пять файловых систем, что перечислены выше: хотя и не все они исконны в этой операционке, но прижились в ней настолько, что "кто из вас роднее — чёрт вас разберёт".

А теперь давайте обратимся к истории и посмотрим, когда эти файловые системы были разработаны.

Файловая система ext2 создана в 1993 году Реми Кардом (Rémy Card) для ликвидации ограничений, присущих первой файловой системе Linux — extended file system (или просто ext), которая была разработана Линусом Торвальдсом для замены MINIX, использовавшейся им поначалу при разработке ядра. Если же учесть, что все традиционные Unix-подобные файловые системы восходят, генетически или парагенетически, к FFS, разрабатывавшейся для первых берклианских Unix'ов, то оказывается, что корни её уходят ещё в начало восьмидесятых годов прошлого столетия (1983 год — создание FFS, давшей таких потомков, как UFS и UFS2 из BSD-мира).

Несмотря на чрезвычайно высокое быстродействие (особенно в сравнении с доминировавшей тогда FAT для DOS/Windows), ext2 имела очень существенные недостатки, главным из которых была неустойчивость при сбоях системы. Конечно, времена, когда аварийное выключение компьютера приводило к полному развалу файловой иерархии, остались в далёком прошлом. Однако нарушение целостности файловой системы при этом было неизбежным, и длительная проверка оной гарантировалась.

Для борьбы с этой напастью были использованы разные средства, такие, например, как SoftUpdates во FreeBSD. Однако магистральная линия развития пошла по пути журналирования файловых операций. Эпонимом журналируемых файловых систем стала JFS, разработанная IBM для собственных RISC-станций и своего же варианта UNIX — AIX (1990-й год). Затем, в варианте JFS2, она была портирована сначала на серверную версию OS/2 (конец 90-х годов), бившейся тогда в последней стадии агонии, а вслед за тем — и на Linux, разумеется. Где она и прижилась под именем просто JFS. И стала, кажется, первой "чужой, но породнившейся" файловой системой, поддержка которой была официально включена в каноническую версию ядра — точной даты не помню, но где-то аккурат рядом с рубежом тысячелетий. Однако широкого признания она тогда не снискала.

Следующей журналируемой файловой системой в Linux стала ReiserFS, разрабатывавшаяся специально для этой ОС Хансом Рейзером и сотрудниками его фирмы Namesys, начиная с конца 90-х годов. Официальную поддержку в каноническом ядре она обрела с выходом его версии 2.4.

Параллельно с этим велись работы по созданию журналируемого варианта традиционной ext2. Каковые в конечном счёте воплотились в ext3, утвержденной в ядре, если мне не изменяет память, в середине 2001-го года (примерно на полгода позже включения ReiserFS). В сущности, ext3 — это не более чем та же самая ext2 с прикрученным к ней журналом.

И, наконец, XFS — файловая система, выпущенная фирмой Silicon Graphics (ныне SGI) в 1994-м году опять же для собственной MIPS-платформы с собственным вариантом UNIX — IRIX. В 2001-м году она была портирована на Linux (под лицензией GPL), однако на протяжении ряда лет в официальном признании со стороны разработчиков ядра ей отказывалось: оно состоялось только с выходом версии 2.6 в самом конце 2003-го года.

Таким образом, можно видеть, что практически все файловые системы, ныне активно используемые в Linux'е, имеют возраст не менее 10-15 лет — а с учётом того, что разработка файловой системы не дело пары выходных дней, и того больше.

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

Однако с другой стороны, с начала разработки файловых систем, активно используемых в наши дни, утекло много воды и сменилось бессчётное количество "железа", так или иначе влияющего на производительность и надёжность файловых операций. И можно сказать, что пользователь, размечающий свой диск под ext2/ext3, XFS или JFS, делает это в совсем другом мире, нежели тот, в котором жили их первые разработчики.

Так давайте заглянем в тот мир. Мир, в котором еще не помышляли о гигабайтных IDE'шниках, а SCSI-винт в 1 Гбайт полагался вполне роскошным даже для сервера. Где плата с кэш-контроллером IDE, вместе с мало-мальски достаточным объемом памяти, стоила почти столько же, сколько и вся остальная машина, вместе взятая. Где еще размышляли о выгодах различных режимов PIO, не догадываясь о прямом доступе к памяти. Где... да мало ли было того, о чём не могли и помыслить мы сами, выступая в роли собственных информационных предков...

И сравним это с тем, что мы видим сейчас:

• быстрые SATA-диски, вплотную приблизившиеся к терабайтному рубежу, со встроенным кэшем, объему которого в годы замысливания файловых систем Linux'а позавидовал бы не то что десктоп, а и не слабый сервер;
• огромные объемы мультимедийных данных, эффективно способствующие заполнению дискового пространства;
• рост объемов единичных файлов — образом полного DVD-диска нынче не удивить уже никого;
• и, наконец, головокружительный обвал цен на винчестеры, превращающий их в самое простое средство резервного копирования.

Ко всему этому не были готовы создатели файловых систем в далёкие девяностые — и, соответственно, не подготовили и свои творения. Конечно, ни одна из наших файловых систем за это время тоже не пребывала в образе застывшего монумента, подвергаясь многочисленным мелким улучшениям. Однако надо отдавать себе отчёт в том, что никаких кардинальных изменений с файловой системой за время её жизни происходить не может: это влечёт за собой потерю совместимости с ней же самой — что мы видели на примере UFS и UFS2 во FreeBSD. Этого счастливо сумела избежать ext3 — но ведь и не так много принципиально нового она дала по сравнению с ext2.

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

• Reiser4, которую не следует смешивать с ныне действующей ReiserFS, это принципиально разные вещи;
• Ext4 — дальнейшее продолжение линии развития Ext2/Ext3, но уже с существенно новыми особенностями и, соответственно, в значительной мере с потерей совместимости;
• Btrfs — файловая система, которой не исполнилось еще и года, но развитие которой до сих пор происходило весьма интенсивно;
• Tux — версионная файловая система, развиваемая вот уже десять лет, но никогда не анонсированная окончательно.

Правда, ни одна из этих систем ещё не доведена до пригодности к безбоязненному практическому использованию. А безбоязненность в отношении сохранности данных — необходимое условие для активного использования файловой системы. Ибо, как говорил Козьма Прутков, в очередной раз восстанавливая свои афоризмы из резервных копий после краха файловой системы, "не шутите с данными, ибо шутки эти глупы и неприличны".

Ближе всех к практическому применению находится Ext4. Она официально поддерживается ядром Linux текущих версий, хотя поддержка эта и квалифицируется как экспериментальная. Тем не менее, она "из коробки" поддерживается в дистрибутиве Fedora (хотя и не предлагается по умолчанию), а в прочих дистрибутивах становится доступной после пересборки ядра и, возможно, обновления пакета e2fsprogs.

Поддержка Reiser4 одно время включалась в некоторые дистрибутивы Linux (например, в Zenwalk версий от 1.3 до 2.8). По отзывам опробовавших её, она была ещё достаточно сырой и не очень надежной. Ныне "из коробки" она не поддерживается ни одним, насколько мне известно, дистрибутивом, и скорого доведения до ума этой файловой системы ожидать не приходится (если таковое состоится вообще).

Файловую систему Btrfs разработчики рассчитывают довести до практической пригодности в рекордные сроки — до конца текущего года. Однако, поскольку за ней стоит компания Oracle, переживающая сейчас не лучшие дни, я не стал бы на это надеяться.

Что касается Tux'а, то её автор, Даниэль Филиппс, в отношении сроков доводки своего детища настроен очень оптимистично. В частности, полагая, что это случится раньше, нежели портирование на Linux файловой системы Hammer из DragonFlyBSD. Впрочем, и тут, с учётом предшествующей истории, оснований для оптимизма я не вижу.

А вот Hammer — файловая система, созданная Мэттом Диллоном для его операционки, DragonFlyBSD, вполне может быть портирована на Linux. Поскольку для работы в своей среде она уже полностью готова. Однако пока что она остаётся во втором эшелоне потенциальных файловых систем для Linux.

Там же, в резерве верховного главнокомандования, можно числить и ZFS — файловую систему, разработанную в фирме Sun первоначально для ОС Solaris, и позднее портированную на FreeBSD. Полноценному использованию её в Linux'е препятствуют лицензионные ограничения, хотя попытки прикрутить её через FUSE и ведутся. Вряд ли это будет радикальным решением — так что остаётся надеяться на то, что кто-то (разработчики ZFS или ядра Linux) поступятся принципами, в результате чего ZFS станет всенародно доступной.

И, наконец, теплится надежда, что кто-нибудь всерьёз возьмётся за прикручивание к Linux'у файловой системы AdvFS — древнего (1993 год) создания фирмы DEC для её платформы Alpha с операционкой Tru64 Unix. Нынешним владельцем она открыта под лицензией GPL, так что препятствий к её портированию на Linux нет ни малейших. И возраст этой системы смущать не должен: как и в ряде других случаев, при разработке AdvFS инженерам DEC удалось "предугадать и предвидеть" тенденции, которые будут реализованы лишь многие годы спустя.

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

Тем не менее, все упомянутые файловые новшества остаются пока в закромах родины. А работаем мы с тем, с чем работаем: пятью файловыми системами, перечисленными в самом начале настоящего раздела. Они-то и будут предметом тестирования, за исключением Ext2, как всё более утрачивающей... Нет, не столько даже актуальность, напротив: с распространением в народе ноутбуков (некоторые даже говорят о вытеснении ими десктопов) с их автономным питанием главный недостаток ext2 — неустойчивость к сбоям, — становится несущественным. Нет, скорее, в увлечении журналируемыми системами про Ext2 просто забыли.

И забыли, возможно, напрасно, о чём я скажу позднее. Потому что, когда все тесты были выполнены, и статья эта в целом написана, я таки не удержался и для очистки совести провёл все измерения и для ext2.

Начиная это тестирование, я ставил перед собой две цели. Первая — посмотреть, как поведут себя традиционные файловые системы Linux в тех самых современных условиях, в обстановке больших и быстрых винчестеров с SATA-интерфейсом и кэшем по 8, 16, а то и 32 Мбайт. И сравнить это с тем, что было совсем недавно, года четыре назад, в ситуации с PATA-дисками, описанной ранее.

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

Я не ждал от результатов тестирования чего-то принципиально нового сравнительно с ранее приводившимися. Хотя, исходя из общих соображений и по аналогии с тестами для файловой системы FreeBSD, можно было бы и предвидеть некоторые неожиданности. Каковые местами и не замедлили последовать.


Первый участник тестирования — это, разумеется, тестовая платформа. Она представляет собой машину на Intel Core 2 Duo о 3 Ггц тактовой частоты, с 6 Гбайт оперативной памяти и двумя винчестерами. Детали конфигурации подробно описаны здесь, поэтому остановлюсь только на дисковой подсистеме.

Оба диска в машине имеют интерфейс SATA-II, скорость вращения 7200 об./мин. Первый из них — 160 Гбайт от Samsung, с 8 Мбайт встроенного кэша, подсоединён к разъёму SATA1 и опознаётся системой как /dev/sda. Второй — 500 Гбайт объема, 16 Гбайт кэша, также от Samsung, подключён к SATA2, и потому является устройством с именем /dev/sdb. Оба диска работают в "родном" для SATA режиме (в данной версии BIOS он именуется Enchanced mode), их формальная производительность по показаниям hdparm такова:

Отступление: в процессе экспериметов с разными системами BSD-семейства я переключал SATA-контроллер в режим совместимости (Compatible mode). Вопреки широко распространенному мнению, никакого снижения тестовой производительности это не повлекло:

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

Первый диск нес на себе:

• раздел с Zenwalk Linux,
• несколько логических разделов с иными Linux'ами,
• первичный раздел под BSD-системы и
• неразмеченное пространство объемом 100 Гбайт, на котором можно было бы создать ещё один первичный раздел (/dev/sda4).

Второй и третий пункты нас сейчас не интересуют, а первый и четвертый будут задействованы в тестировании.

На втором диске притулилсь первичный и несколько расширенных разделов, содержимое которых нам опять же не важно, раздел на 300 Гбайт, несущий файловую систему ext3, подмонтированную к файловой структуре Zenwalk'а с первого диска в каталог /home, и остаток — 100 Гбайт неразмеченного пространства, могущего быть превращённым в первичный раздел (/dev/sdb4).

Второй участник тестирования — операционная система, в качестве которой выступает поминавшийся выше Zenwalk Linux в версии 5.2, модифицированный до снапшот-версии по состоянию на 5 сентября 2008 года. В нём использовалось ядро версии 2.6.26.3.

И, наконец, исполнительницы главных ролей в нашей постановке — файловые системы: ext3, reiser, XFS и JFS, к которым под занавес присоединилась ext2. В первом акте пьесы они последовательно создавались на разделе /dev/sdb4 посредством соответствующих каждой из них утилит, с параметрами по умолчанию. После этого они последовательно монтировались в каталог /home/mnt, которому приписывались атрибуты, допускающие в него обычного пользователя, от лица которого и проводились действия по собственно тестированию.

Для разных файловых систем применялись допустимые в них опции монтирования:

• ext3 последовательно монтировалась во всех трёх её режимах, data=ordered (тот, что применяется по умолчанию), data=journal (с полным журналированием метаданных и данных) и data=writeback (журналирование исключительно метаданных);
• для reiser сначала проводилось монтирование по умолчанию, а потом — с опциями notail,noatime;
• XFS, JFS, а потом и ext2 монтировались только с параметрами по умолчанию.

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

В антракте, когда все зрители бросились в буфет за пивом, тип разделов /dev/sda4 и /dev/sdb4 был переопределён как Linux autodetect RAID (FD), и они посредством утилиты mdadm были объединены в RAID-массив нулевого уровня с размером chunk'а по умолчанию.

Далее история повторялась — на объединенном в массив устройстве /dev/md0 последовательно создавались те же файловые системы, и таким же образом. А при монтировании я ограничился режимами ordered и journal для ext3, опциями notail,noatime для reiser и умолчальными — для всех остальных.

С участниками покончено, пора переходить к объектам. Файловые системы подвергались мучительству посредством двух операций — копирования и удаления файлов. В качестве последних выступали:

• каталог с 16 музыкальными файлами формата FLAC, размером от 10 до 27 Мбайт, суммарным объёмом 357 Мбайт;
• дерево портежей Gentoo, включающее более 12 тысяч файлов и подкаталогов, размером от нескольких сот байтов до первых килобайт, при суммарном объёме каталога около 229 Мбайт; не из какого-либо пристрастия к этому дистрибутиву — просто снапшот портежей оказался у меня под рукой;
• avi-файл, сшитый из всех пяти серий фильма "Адьютант его превосходительства", объемом 3,4 Гбайт;
• iso-образ компакт-диска (дистрибутив Xubuntu 8.04.1 Alternate), объёмом 586 Мбайт.

Объекты тестирования местом постоянного пребывания имели один из подкаталогов /home, то есть лежали на разделе /dev/sdb3. Тестирование же проводилось, как я уже говорил, сначала на устройстве /dev/sdb4, затем — на /dev/md0.


Так что первым тестом было измерение времени копирования массива данных, которые будут использоваться в дальнейшем, с раздела /dev/sdb4 на целевое устройство — /dev/sdb4 или /dev/md0. Казалось бы, зачем? Ведь представляется очевидным, что манипуляция с массивом должна занимать примерно столько же времени, сколько суммарное время манипуляций с его составляющими. В общем-то, да, но, как мы вскоре увидим, не всегда.

Далее в случае каждой файловой системы и различных режимов её монтирования командой вида

последовательно копировались (в пределах целевого устройства и его файловой системы) каталог с музыкальными файлами, дерево портежей, avi- и iso-файлы. Затем новобразованные копии столь же последовательно удалялись командой

Время каждой операции замерялось по выводу команды date перед её началом и после успешного завершения, по схеме

Почему date, а не time? Во-первых, так уж исторически склалось. А во-вторых, первые тесты по быстродействию файловых систем я проделывал для сравнения таковых для Linux и для FreeBSD, да и впредь собираюсь этим заниматься. А ломать голову над приведением к общему знаменателю вывода команды time для этих операционок мне не хочется. Тем более, что команды date вполне достаточно.

Конечно, точность её не высока - до секунды. Однако если разница во времени выполнения двух операций меньше — можно смело полагать, что она (то есть разница) вовсе отсутствует.

Итак, вся серия тестов была проделана сначала для файловых систем на разделе /dev/sdb4, а затем — на устройстве /dev/md0. Результаты измерений сведены в таблице, к последовательному рассмотрению которой мы и переходим.


Начнём с операций на дисковом разделе /dev/sdb4 и с файловой системы ext3fs, сравнив различные режимы её монтирования. Для начала бросается в глаза, что бытующее мнение о том, что наиболее "мягкий" режим журналирования, writeback, при котором фиксируются только изменения метаданных, обладает какими-то преимуществами в быстродействии, не находит подтверждения. В скорости "валового" копирования всего массива данных он даже несколько проигрывает умолчальному режиму ordered (полное журналирование операций с метаданными и частичное — с данными). А в каждой из дискретных операций копирования результаты при этих режимах можно считать равными — вряд ли выигрыш в четыре секунды при копировании avi-файла и такой же проигрыш при копировании дерева портежей можно считать значительным.

Привлекает внимание то, что скорость "валового" копирования не равна сумме времени, затраченного на дискретные его операции — она несколько больше. Такую же картину мы увидим и для остальных файловых систем, за единственным исключением. И она в принципе объяснима: поскольку при "валовом" копировании источник и цель находятся на различных разделах диска весьма приличных размеров, резонно ожидать, что время на перемещение считывающих головок оказывается больше, нежели когда данные копируются в пределах одного и того же раздела.

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

Сколько-нибудь значимо только время удаления дерева портежей — и это тоже понятно, так как операция эта требует обращения ко множеству inodes. А вот удаление всего массива данных опять же занимает больше времени, нежели сумма отдельных операций удаления.

Теперь посмотрим на поведение файловой системы ext3 в режиме полного журналирования (то есть операций как с данными, так и метаданными). Со времён известных статей Дэниэла Роббинса, написанных в 2001 году, в ходу легенда о том, что в режиме ordered некоторые операции выполняются даже быстрее, чем при частичном журналировании или журналировании только метаданных, под что подводилось и теоретическое обоснование.

В те далёкие времена такое в отдельных случаях случалось. Так, по моим измерениям, проведённым в 2004 году (их можно видеть здесь, режим jourmal выигрывал (и весьма значительно) у ordered и writeback на копировании очень большого количества очень маленьких файлов (тогда в качестве примера таковых выступало дерево портов FreeBSD).

Ныне же мы видим стабильное отставание режима полного журналирования на всех операциях копирования по сравнению с обоими режимами журналирования частичного — и это отставание в полтора-два раза. Так что — увы, но чудеса на свете случаются очень редко, и журналирование операций с данными требует времени. Хотя удаление дерева портежей при всех режимах оказывается практически одинаковым.

Файловая система reiser монтировалась в двух режимах. Первый — умолчальный, с включением так называемой "упаковки хвостов" (tailing) то есть конечных частей файлов, занимающих меньше логического блока файловой системы, что обеспечивает экономию дискового пространства, но, теоретически, должно снижать быстродействие. Второй же режим — монтирование с опциями notail,noatime, первая из которых отключает режим тайлинга, а вторая, заодно уж, и запрещает обновление атрибута времени последнего обращения к файлу (access time), что также должно способствовать производительности.

На практике эти теоретические ожидания оправдываются не всегда. Время "валового" копирования при отключении тайлинга и обновления atime даже возросло, результаты по отдельным операциям копирования осталось практически неизменным, а вот время удаления как дерева портов, так и всего массива данных действительно сократилось в два и полтора раза соответственно. Впрочем, оно и так было крайне небольшим (особенно в сравнении с ext3 в любых режимах), да и не каждый день приходится истреблять такое количество столь мелких файлов. Так что вряд ли это можно считать существенным практическим ростом производительности.

Файловая система XFS принесла самые большие неожиданности, которые нельзя было предвидеть по результатам моих прежних измерений, и объяснения которым я пока не вижу.

Уже на стадии "валового" копирования с исходного раздела на раздел тестовый время этой операции существенно зашкалило за 14 минут, тогда как для всех остальных файловых систем оно колебалось от 3:51 (reiser, defaults) до 7:11 (ext3, journal).

Разумеется, первая мысль была о какой-нибудь ошибке. Однако я решил досмотреть действие до конца, чтобы увидеть, какая из операций обеспечивает такой весомый вклад в замедление работы.

Оказалось, что время копирования внутри раздела каталога с музыкой, avi- и iso-файлов для XFS сопоставимо с длительностью тех же операций для ext3 и reiser. А вот время копирования дерева портежей — не просто много больше, но и превышает суммарное время "валового" копирования с раздела на раздел, составляя почти 17 минут (см. табл., строка XFS defaults 1). Время удаления дерева портежей и "вала" также оказалось "рекордным", составив десять минут с небольшими копейками.

Результаты эти настолько выбивались из общей картины и всего, что я знал о файловых системах по предыдущим измерениям, что, повторяю, мысль об ошибке возникала сама собой. Поэтому я не применул повторить тест — и не просто перемонтировав файловую систему, но уничтожив раздел, на котором она лежала, обнулив его начальные сектора, создав раздел заново и воссоздав на нём файловую систему XFS, правда, опять-таки с параметрами по умолчанию, не занимаясь расчётами того, на сколько гигабайт должна приходиться одна allocation group.

Однако, как сказал бы Ослик ИА, с этой стороны было ничуть не лучше: результаты измерения скорости выполнения всех операций повторились в пределах погрешности опыта (см. табл., строка XFS defaults 2). Да, конечно, XFS никогда не славилась скоростью работы с маленькими файлами, а задумчивость её при удалении оных превратилась уже в фирменную "фичу", и мои прежние результаты это подтверждали — но не до такой же степени...

В общем, единственное, что приходит в голову — это какое-то фатально наудачное сочетание умолчальных параметров форматирования XFS с геометрией конкретного диска. Разрешение этой загадки оставляю на усмотрение заинтересованных лиц, поскольку, как будет явствовать из дальнейшего, сам я интерес к этой файловой системе утратил полностью.

Теперь перейдём к JFS. Эта файловая система всегда была для меня тёмной лошадкой: !!!в отличие от всех прочих актёров нашего файлового театра, на премьерах с её участием я не бывал — то есть сам практически её не использовал!!!. А беглый взгляд при репетиции (то есть всё том же давнишнем тестировании не вызвал у меня никаких эмоций — ни положительных, ни отрицательных. Хотя репутация JFS, как системы, исключительно устойчивой ко всякого рода сбоям, была мне известна.

Собственно, и в сводную труппу участников нынешнего тестирования я включил её в основном полноты картины ради — и не пожалел об этом, она добавила чуток цимесу в весь сюжет пьесы.

Итак, созданная и смонтированная по умолчанию (а какие параметры форматирования и монтирования её могли бы сыграть роль, я, честно говоря, не разбирался), она показала довольно большое время "валового" копирования с раздела на раздел: если исключить ураганные значения для XFS, медленнее её оказалась только ext3 в режиме полного журналирования. А вот на дискретных "внутрираздельских" операциях копирования результаты её были не лучше и не хуже всех остальных файловых систем. Правда, при удалении файлов она оказалась не на высоте, заняв почетное второе с конца место, после XFS, абсолютного анти-чемпиона по этому показателю.

И, наконец, старушка ext2. Тут всё обошлось без неожиданностей: довольно приличное время "валового" копирования с раздела на раздел, что определяется главным образом длительностью копирования avi-файла (больший показатель только у ext3 в режиме journal), скорость же выполнения остальных операций — на уровне остальных или в числе лучших.

Теперь посмотрим, что получилось после описанных ранее событий в антракте — создании программного RAID'а. Количество участников в этом акте у нас поубавилось — по одному от каждой файловой системы, лишь для ext3 я решил посмотреть, насколько программный RAID способен скомпенсировать задумчивость её режима journal.

В общем, программный RAID превзошёл мои ожидания. У меня и раньше было ощущение, что он существенно ускоряет все дисковые операции, но, как мы знаем по многим примерам, ощущения — ощущениями, а измерения — измерениями.

Так вот, согласно измерениям, использование программного RAID'а кардинально повышает производительность всех операций на всех файловых системах, давая прирост быстродействия от 30 до 100 %. Правда, чудес и тут нет. То есть инверсии призовых мест не наблюдается: каков бы ни был относительный прирост для каждой файловой системы и отдельной операции в ней, лидеры остаются лидерами, а аутсайдеры — аутсайдерами.

Хотя единственное чудо, правда, наполовину, всё же имеет место быть: использование XFS поверх RAID'массива ликвидирует её аномальное отставание при обращении с деревом портежей.

А вообще, наступил психологический момент поглядеть, как ведут себя файловые системы (и на разделе, и на RAID'е) при выполнении каждой дискретной операции. В этом деле нам поможет серия диаграмм (рис. 1-5).

На рис. 1 мы видим относительную скорость копирования каталога с музыкальными файлами.


Здесь выделяются абсолютный лидер — ReiserFS на RAID-массиве и столь же бесспорный аутсайдер — ext3 на разделе в режиме полного журналирования.

Нога в ногу с лидером идут другие файловые системы на массиве — XFS, ext3 в умолчальном режиме и, чуть отставая от них, JFS. А вот полностью журналируемой ext3 RAID позволяет лишь достичь плато всех остальных файловых систем, базирующихся на разделе.


В тесте на копирование avi'шки (рис. 2) XFS, наконец, удаётся поддержать свою репутацию файловой системы, созданной для работы с очень большими файлами и RAID-массивами: именно в этом сочетании она оказывается первой на пьедестале почёта. Впрочем, справедливости ради надо отметить, что над ступенькой второй, на которой тесняться reiser и JFS на RAID'е, она возвышается всего чуть-чуть, да и третья ступенька не особенно прогнулась под тяжестью умолчальной ext3 вместе с несущим её массивом. В полностью журналируемом же её варианте RAID даёт ей возможность занять аккурат среднее положение между остальными файловыми системами на массиве и их собратьями на разделе, образующими ровную плоскость, из которой ввысь, к зияющим высотам медлительности, опять же устремляется ext journal.


Копирование iso'шника (рис. 3) даёт в целом ту же самую картину. С той лишь разницей, что теперь за второе место, с минимальным отрывом от XFS на RAID, борются reiser и ext3 ordered, также базирующиеся на массивах. А JFS на RAID'е уступает ext3 journal на нём же, фактически сливаясь с плоскостиной файловых систем, базирующихся на разделах. Впрочем, ext3 journal на разделе по-прежнему высится одиноким и недосягаемым пиком.

При обсуждении диаграмм, иллюстрирующих операции с деревом портежей (рис. 4 и 5), следует обратить внимание на то, что в них не фигурируют откровенно экстремальные значения для XFS, базируемой на разделе: без вских картинок ясно, что она оказывается много медленнее всех остальных файловых систем при любых условиях.


А вот на RAID'е при копировании дерева портежей XFS оказывается вровень с файловой системой, считающейся самой быстрой при работе с очень маленькими файлами — с reiser; правда, при условии, что последняя лежит на обычном разделе. Ибо та же reiser на RAID'е опять отхватывает себе чепмионскую майку, обходя, правда, не очень значительно, базирующуюся на RAID'е же ext3, на этот раз — в обоих режимах её монтирования. Ну а ext3 journal наконец-то уступает (мало)почётное последнее место JFS на разделе, хотя последняя на RAID'е выглядит вполне сносно.


И при удалении дерева портежей (рис. 5) пальма первенства по-прежнему у reiser — причем вне зависимости от того, лежит она на разделе или на RAID'е. А вот на последнем месте прочно окопалась JFS — и опять же и при одном, и при другом месте базирования.

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


В варианте на разделе (рис. 6) ext2 идёт или вровень с коллегами (копирование музыки и iso-файла), либо с приличным опережением, как при копировании дерева портежей, где она обходит даже признанного фаворита — reiser. Лишь при копировании avi'шки она существенно отстаёт от всех прочих: что поделать, ни Линусу, ни Реми файлы размером в три-четыре гигабайта не могли привидиться и в кошмарном сне.


А вот пребывая на RAID-массиве (рис. 7), ext2 оказывается далеко не последней даже в этой чуждой для себя сфере. И ещё больше увеличивается её отрыв от конкурентов при копировании дерева портежей, при примерно равных результатах на копировании музыки и iso-образа.


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

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

Это можно видеть на примере ext2fs. Кстати, похоже, что именно она получила и наибольший выигрыш от переноса с раздела на RAID, как относительный, так и абсолютный. Так что для тех, чей кумир — быстродействие любой ценой, выбор по-прежнему очевиден.

Да, ext2 плохо переносит сбои питания. Но сейчас, когда десктопы, требующие источников бесперебойного питания (приобрести которые у домашних пользователей часто не доходят руки или кошельки), всё больше замещаются ноутбуками, несущими бесперебойники в себе, эта проблема не стоит так остро. Так что для фанатов быстродействия, не очень часто имеющих дело с очень большими файлами и файловыми системами, да к тому же владельцев ноутбука, ext2 — первый кандидат.

В качестве второго кандидата можно рассматривать ReiserFS — пожалуй что лидера по интегрированному быстродействию среди журналируемых файловых систем. Она одинаково хорошо обращается и с большим количеством мелких файлов, и с файлами очень большого размера. Не ударит она в грязь лицом и на всех промежуточных вариантах. При этом получая существенный выигрыш почти на всех операциях при помещении её на RAID.

Очевидны и интегральные аутсайдеры с точки зрения быстродействия — это ext3 в режиме полного журналирования и JFS. Характерно при этом, что обе эти файловые системы считаются наиболее устойчивыми к сбоям. Правда, как оценить этот фактор, я не знаю: банальное отключение электричества в обстановке настольного (домашнего, например) десктопа безболезненно переносится любой из наших файловых систем, кроме ext2, а с более критическими ситуациями на практике я не сталкивался.

Тем не менее, для пользователей, ставящих во главу угла фактор надёжности, и ext3 journal, и JFS будут подходящим выбором. Причем JFS — похоже, более подходящим: всё-таки суммарно она оказывается несколько быстрее, нежели ext3 journal.

С другой же стороны, ext3 оказывается самым гибким решением — различные её режимы задаются при монтировании, и переход от ext3 journal к exte ordered и наоборот весьма прост Если к этому добавить совместмость и, так сказать, привычность, то ext3, особенно в варианте ordered, оказывается хорошим выбором для умеренного консерватора, любящего сбалансированные, хотя и не претендующие на рекордность решения.

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

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

XFS, напротив, будет плохим выбором для файловых систем, содержащих большое количество мелких и часто обновляемых файлов. То есть задействовать её под такие ветви файлового древа, как /var, /tmp, различные портообразные системы, если они выносятся на самостоятельные разделы, будет не очень разумно.

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

Как мне надоело использование древних технологий и то, что каждый производитель использует что-то свое, форматы у всех разные. А стандартизировать, чтобы пользователям было проще. И все это из-за таких компаний, как "наша любимая" Microsoft(которые сейчас все-таки лучше стали работать, чем раньше, ПО более качественное, но все равно с косяками, деньги хапают, но меньше), Sun и Oracle, которым лишь бы срубить бабла побольше. Что толку говорить, если разработчикам наплевать.
Вы знаете, например, что многие пользователи Хрома ругали его загрузчик, жаловались Google, а что мы видим? какой был, такой и остался-тормозной и без возможности докачки. А эта функция сейчас нужна очень многим, даже тем, у кого хороший и быстрый интернет. Не у всех есть очень высокие скорости, не в каждом регионе нормальные тарифы и не все сервера хорошо отдают, поэтому функция докачки будет популярна, пока есть такая фигня. Жалуйся-не жалуйся-все равно абсолютно ничего не изменится, потому что некоторым разработчикам наплевать, а некоторые тянут резину.

Это наоборот хорошо, что есть разные варианты - каждый заточен под свои цели. Возможно есть и откровенная халтура, но она как правило себя сразу показывает. Еще надо временную поправку взять - материал статьи уже 2-годичной давности, а за два года многое может поменяться.