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

Самое простое дело — это файловая система для раздела под /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. Именно тут она покажет все свои прелести, а пользователь сможет насладиться несравненным быстродействием файловых операций.


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