Новелла тридцать седьмая, посвящённая выбору файловых систем

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

Самое простое дело — это файловая система для раздела под /boot: небольшой и редко изменяемый, он не нуждается в журналировании. И потому на него просто просится ext2fs или ext4fs без журнала. Минус этого решения: при системном сбое или сбое по питанию раздел не получит бита чистого размонтирования и подвергнется проверке и восстановлению через fsck, возможно (хотя и крайне маловероятно), что с фатальным результатом.

Купировать это можно, во-первых, источником бесперебойного питания, а во-вторых и главных — отказом от автоматического монтирования /boot при старте системы (как и рекомендуют разработчики загрузчика GRUB). Поскольку его содержимое изменяется только при обновлении ядра (а в стабильных релизах пакетных дистрибутивов это дело не частое), примонтировать его руками на это время — не такой уж великий труд.

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

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

Файловая система ext4fs обеспечивает оптимальное соотношение между надёжностью, совместимостью и быстродействием, и потому в большинстве инсталляторов современных дистрибутивов предлагается по умолчанию, заняв амплуа ext3fs.

У ext4fs есть ещё один плюс: как уже говорилось, она безболезненно может быть преобразована в btrfs — когда и если (и если и когда) вам захочется встать на острие технического прогресса. Именно поэтому, в том числе, и необходим загрузочный раздел с чем-то традиционным — ни GRUB, ни Lilo загрузить ядро с btrfs-раздела не в силах, на это способен только GRUB2. А его использование не всегда целесообразно.

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

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

В старых сетевых материалах можно найти упоминания о том, что GRUB не может загрузить ядро Linux раздела под ReiserFS, и рекомендации обязательно создавать загрузочный раздел с ext2fs/ext3fs. Некогда (совсем-совсем недавно, лет сто десять назад) это действительно имело место быть. В причины явления сейчас вдаваться неуместно — важно лишь то, что оно давно изжито. Почти как пьянство при последнем генсеке.

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

Наконец, в качестве кандидатов на «корневой статус» осталось рассмотреть две последние системы — JFS и XFS. На мой взгляд, использование обеих в этом качестве не целесообразно. Первой — потому что её нецелесообразно использовать под Linux’ом вообще. А второй — по той же причине, что и btrfs: на корне XFS просто негде блеснуть своими достоинствами.

Несколько иной расклад будет при выборе файловой системы для /home (или отдельных разделов внутри этого каталога, в соответствие с ранее описанной схемой). И тут надо исходить из характера преобладающих пользовательских данных. Если приходится работать преимущественно с большими файлами, то стоит подумать о XFS, если с маленькими — напрашивается ReiserFS. Ну а ext4fs и здесь окажется разумным и близким к оптимальному выбором.

Здесь нужно помнить, что при разделении /home на отдельные ветки первичными разделами уже не обойтись, потребуется использовать логические разделы в Extended Partition. Если это почему-либо нежелательно или невозможно (например, расширенный раздел уже задействован под более иную ОС — а ведь мы помним, что он может быть только один, да и что это за ОС, тоже знаем), то есть смысл обратиться к btrfs. В этом случае создаётся единый раздел под /home, а внутри него определяются субтома (в обозначениях btrfs, о чём речь будет позднее) @/username, @/current, @/data, @/media и что потребуется впредь.

Это имеет два плюса: во-первых, снимается необходимость расчёта дискового пространства под каждый из разделов внутри /home, во-вторых, при необходимости в любой момент легко добавить ещё один субтом.

И в заключение рассмотрим случай двух примерно одинаковых дисков. Как уже говорилось, в этом случае есть смысл объединить их (за исключением загрузочного раздела или их пары) в RAID Level 0,, который далее размечается как обычный диск — на корневой раздел, раздел под /home и, возможно, отдельные его ветви. И если для корневого раздела файловая система более-менее безразлична (например, на него можно водрузить палочку-выручалочку — ext4fs), до разделу домашнему сотоварищи самой судьбой предназначена XFS. Именно тут она покажет все свои прелести, а пользователь сможет насладиться несравненным быстродействием файловых операций.


Назад | К содержанию | Вперёд