До недавнего времени список истинно родных (native) файловых систем для Linux ограничивался единственной – ext2fs (правда, Linux способен загрузиться и работать с FAT-раздела, но об этом мне даже не хочется говорить). Название это расшифровывается как "вторая расширенная файловая система"; "расширенная" она – по сравнению с файловой системой ОС minix, послужившей прототипом Linux, "вторая" – потому что ранние версии Linux базировались на Extfs с более ограниченными возможностями.

О файловой системе Ext2fs написано немало (см. дополнительные источники). Поэтому замечу только, что по способу организации хранения данных она – типичная представительница файловых систем Unix. Отличительная ее особенность – наличие нескольких копий суперблока, что повышает надежность хранения данных. Кроме того, для характерен очень эффективный механизм кэширования дисковых операций, что обеспечивает замечательное их быстродействие – едва ли не рекордное среди известных мне файловых систем. Оборотная сторона чего, однако, – относительно слабая устойчивость при аварийном завершении работы (вследствие мертвого зависания или отказа питания), поскольку отложенность записи изменений файлов делает весьма высокой вероятность нарушения связи между их inodes и блоками данных.

Конечно, времена, когда некорректный останов Linux-машины грозил полным разрушением файловой системы, остались в далеком прошлом. Однако в любом случае останов системы без штатного размонтирования файловых систем приводит к тому, что в них не устанавливается упомянутый выше "бит чистого размонтирования". А без этого утилиты обслуживания диска (такие, как программа проверки fsck) при перезагрузке не воспринимают их как целостные и начинают проверку, которая при современных объемах дисков может занять немалое время.

Проблема нарушения целостности файловой системы при некорректном завершении работы в большей или меньшей мере характерна для всех ОС семейства Unix. И потому с давних пор в них разрабатываются т.н. журналируемые файловые системы. Журнал -- это нечто вроде log-файла дисковых операций, в котором фиксируются не выполненные, а только предстоящие манипуляции с файлами, вследствие чего оказывается возможным самовосстановление целостности файловой системы после сбоя.

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

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

Текущие версии ядра Linux поддерживают в качестве нативных четыре журналируемые файловые системы: ReiserFS и Ext3fs, специфичные для этой ОС, XFS и JFS – результаты портирования в Linux файловых систем, разработанных первоначально для рабочих станций под ОС Irix (SGI) и AIX (IBM), соответственно. Правда, широкое признание получили только три первых, так что о JFS я пока говорить не буду.

Файловая система ReiserFS оказалась для Linux исторически первой из журналируемых – она поддерживается каноническим ядром c http://www.kernel.org, начиная с первых версий ветви 2.4.x (в настоящее время существуют патчи, позволяющие использовать ее и с версиями ветви 2.2.xx). И была единственной, разработанной "с нуля" специально для этой ОС Хансом Райзером и его фирмой Namesys. Как и в большинстве рассмотренных, в ReiserFS осуществляется журналирование только операций над метаданными файлов. Что, при определенном снижении надежности, обеспечивает высокую производительность: по моим наблюдениям, на большинстве типичных пользовательских задач она лишь незначительно уступает Ext2fs. А на такой, достаточно обычной, операции, как копировании большого количества мелких файлов, существенно ее опережает.

Кроме этого, ReiserFS обладает уникальной (и по умолчанию задействованной) возможностью оптимизации дискового пространства, занимаемого мелкими, менее одного блока, файлами (а следует помнить, что в любой Unix-системе такие файлы присутствуют в изобилии): они целиком хранятся в своих inode, без выделения блоков в области данных – вместе с экономией места это способствует и росту производительности, так как и данные, и метаданные (в терминах ReiserFS – stat-data) файла хранятся в непосредственной близости и могут быть считаны одной операцией ввода/вывода.

Вторая особенность ReiserFS – то, что т.н. хвосты файлов, то есть их конечные части, меньшие по размеру, чем один блок, могут быть подвергнуты упаковке. Этот режим (tailing) также включается по умолчанию при создании ReiserFS, обеспечивая около 5% экономии дискового пространства. Что, правда, несколько снижает быстродействие, и потому режим тайлинга можно отменить при монтировании файловой системы. Однако упаковка хвостов автоматически восстанавливается после перекомпиляции ядра – что, как будет сказано чуть ниже, требует внимательного отношения.

ReiserFS не совместима с Ext2fs на уровне утилит обслуживания файловой системы. Однако соответствующий инструментарий, объединенный в пакет reiserfsprogs, уже давно включается в штатный комплект современных дистрибутивов (или, в крайнем случае, может быть получен с сайта Namesys).

Более серьезная проблема с совместимостью – в том, что распространенные загрузчики Linux (и Lilo, и GRUB – хотя и по разным причинам) часто не способны загрузить ядро Linux с раздела ReiserFS, оптимизированного в режиме тайлинга. А поскольку, будучи отключен, этот режим обладает свойством самовосстановления, пользователь может столкнуться с тем, что после пересборки ядра система просто откажется загружаться. Именно поэтому выше я упоминал, что создание раздела под каталог /boot может быть необходимым.

В отличие от ReiserFS, Ext3fs – не более чем журналируемая надстройка над классической Ext2fs, разработанная Стивеном Твиди в компании Red Hat и поддерживаемая ядром Linux, начиная с версии 2.4.16. Как следствие такого происхождения, она сохраняет со своей прародительницей полную совместимость, в том числе и на уровне утилит обслуживания (начиная с версии 1.21 объединяющего их пакета e2fsprogs). И переход от ext2fs к ext3fs может быть осуществлен простым добавлением файла журнала к первой, не только без переформатирования раздела, но даже и без рестарта машины.

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

В Ext3fs предусмотрено три режима работы – полное журналирование (full data journaling), журналирование с обратной записью (writeback), а также задействуемое по умолчанию последовательное (ordered).

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

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

В последовательном режиме также физически журналируются только метаданные файлов, однако связанные с ними блоки данных логически группируются в единый модуль, называемый транзакцией (transaction). И эти блоки записываются перед записью на диск новых метаданных на диск, что, хотя и не гарантирует сохранности данных, весьма последней способствует. Причем – при меньших накладных расходах по сравнению с полным журналированием, обеспечивая промежуточный уровень быстродействия.

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

Файловая система XFS, в отличие от молодых ReiserFS и ext3fs, развивается для фирмой SGI на протяжении почти десяти лет – впервые она появилась в версии Irix 5.3, вышедшей в 1994 г. Но в Linux она была портирована лишь недавно (текущая ее версия – 1.1, свободно доступна с сайта SGI's XFS page – http://oss.sgi.com/projects/xfs) и по сию пору не поддерживается официальным ядром.

XFS – единственная 64-разрядная файловая система из рассмотренных. Однако уникальность ее – не только в этом. Особенностями XFS являются:

В результате XFS предстает как очень сбалансированная файловая система: она почти столь же надежна, как Ext3fs, и не очень уступает ReiserFS в быстродействии на большинстве файловых операций. А при манипуляциях с (очень) большими файлами XFS – просто вне конкуренции: как легко догадаться по имени фирмы-разработчика, она ориентирована на работу с мультимедийными приложениями с их огромными потоками данных. Не отмечалось для нее и проблем с совместимостью.

Все сказанное позволяет сделать вывод, что XFS – оптимальная файловая система для Linux. Однако следует учесть: в отличие от ReiserFS и ext2fs, поддержка которых является штатными опциями ядра Linux, XFS по сию пору (текущая версия – 2.4.19) не поддерживается каноническим ядром Линуса Торвальдса (тем, которое можно получить с http://www.kernel.org). Хотя недавнее включение такой поддержки в разрабатываемую ветвь ядра (версии 2.5.X) позволяют надеяться, что скоро эта функция станет штатной.

Возможность работы с XFS обеспечивает специальный патч (xfs-2.4.1X-all-i386.bz2), который можно получить с сайта SGI вместе с соответствующими утилитами поддержки: традиционные средства e2fsprogs, для XFS не пригодны. Утилиты поддержки для XFS объединены в несколько пакетов, из которых абсолютно необходимым является xfsprogs. Обо всем этом следует помнить при предварительной разметке диска.

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

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

Так, ранее неоднократно говорилось, что Ext2fs – наиболее подходящий выбор для загрузочного раздела (а при использовании в качестве загрузчика GRUB – это почти обязательное требование). Кроме того, Ext2fs вполне подходит для таких ветвей, как /tmp или /var. Для первого, по определению, устойчивость к сбоям не критична. Для второго же определяющим требованием является быстродействие (так, в Source Based дистрибутивах типа Gentoo /var задействуется для хранения временных продуктов компиляции, и быстродействие файловых операций в нем несколько способствует ускорению сборки пакетов). Наконец, на настольной машине Ext2fs можно применить и для корневой файловой системы – ведь при дробном разбиении диска в корне остается минимум редко изменяемых компонентов.

С другой стороны, корень – наиболее критичный в отношении устойчивости элемент файловой системы. И потому оптимальным для него представляется файловая система Ext3fs, как наиболее устоявшаяся. Кроме того, в экстремальных ситуациях она может быть без проблем смонтирована как Ext2fs. Для разделов типа /usr и /usr/local Ext3fs также видится вполне подходящим вариантом.

Наиболее важная часть файловой системы настольной машины с точки зрения пользователя – его, пользовательские, данные, то есть каталог /home (ибо систему можно переустановить, а вот потеря данных может быть невосполнимой). Однако это – и наиболее изменяемая ее часть, что предъявляет высокие требования к быстродействию файловых операций. И поэтому Ext3fs – не лучшее (ИМХО) решение для каталога /home, более целесообразно разместить здесь какую-либо из "быстрых" журналируемых файловых систем, ReiserFS или XFS. Выбор между ними определяется личными предпочтениями и характером данных (пользуясь случаем, замечу, что быстродействие JFS, по моим наблюдениям над типичными пользовательскими манипуляциями, оставляет желать лучшего).

Очевидно, что быстродействие XFS при работе с файлами (очень) большого размера делает ее предпочтительной, если речь идет об обработке изображений, мультимедийном контенте, картографической информации и т.д. В то же время преимущества ReiserFS сказываются в основном при работе с файлами (очень) маленького размера (менее блока файловой системы), каковых среди пользовательских данных обычно бывает мало. И потому мое личное мнение однозначно – и высказывается в пользу XFS. К тому же собственный опыт общения с ReiserFS был неблагоприятен, особенно в сочетании с технологией LVM. XFS же, напротив, по моим впечатления идеально с ней гармонирует.

Подведем итог – оптимальной мне видится следующее сочетание файловых систем:

Повторяю, это лишь мое мнение, основанное на опыте настольного применения Linux – для серверов различного рода оно силы не имеет.