Стратегия дисковой разметки: былое и ныне

Алексей Федорчук

О дисковой разметке в Unix-подобных (или POSIX-совместимых) операционных системах написано немало. Много копий было сломано в форумных обсуждениях того, насколько дробно следует размечать диск, каковы предпочтительные файловые системы в зависимости от назначения, какие опции форматирования и параметры монтирования следует задавать для отдельных ветвей файловой иерархии, выносимых на самостоятельные разделы. А также теоретическим вопросам — насколько практика разметки, форматирования монтирования согласуется с квази-законодательным документом — стандартом файловой иерархии, FHS (Filesystem Hierarchy Standard).

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

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

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

1. всё сказанное относится к настольному десктопу (или ноутбуку, выполняющему роль первой, а то и единственной, машины) конечного, в первую очередь домашнего, пользователя — ибо автор причисляет себя именно к этому сословию; для серверов или сетевых рабочих станций индустриального применения всё может быть иначе; также нет необходимости заботиться о сложной дисковой разметке для ноута или нетбука, играющего роль второй машины;
2. предлагаемая схема рассчитана на применение, по крайней мере эпизодическое, более чем одного дистрибутива или операционной системы — ведь какой же линуксоид время от времени не устанавливает, в дополнение к основной рабочей системе ещё какой-либо дистрибутив или ОС в экспериментальных целях; причём нельзя исключить вероятности того, что экспериментальная система станет со временем основной.

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

Что же до повышения надёжности, обеспечиваемого, например, RAID-массивами с избыточностью, то в условиях настольного десктопа оно также кажущееся: вряд ли у кого из «домашних» пользователей в ящике стола валяется без дела запасной винчестер, которым можно заменить вышедший из строя компонент массива. А буде таковой и имеется — проще и надёжней прикрутить его в качестве резервного хранилища, заполняемого вручную или в полуавтоматическом режиме, посредством какой-либо-cron-подобной утилиты.

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

Это одна сторона «железного» вопроса. Другая же — не за горами массовое внедрение SSD-накопителей, по крайней мере, в качестве системных: как замена больших хранилищ данных они не скоро ещё станут конкурентоспособны относительно традиционных винчестеров (если когда-нибудь станут вообще).

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

Для ноутбука подобные рекомендации выполнить довольно трудно — разве что в качестве хранилища данных использовать внешний винчестер с интерфейсом eSATA, но машины с этим разъёмом пока довольно редки.

А вот для нетбуков, как это ни парадоксально, указанную конфигурацию собрать достаточно легко: можно найти модель с небольшим SSD-накопителем и прикрутить к ней всё тот же внешний винчестер. Правда, нетбуков с eSATA я пока не видел — но думаю, их появление не за горами.

Теперь о принципах разметки. Их два:

1. обособить системную часть от пользовательских dot-файлов, с одной стороны, и от собственно данных — с другой;
2. обеспечить доступ к пользовательским данным из различных дистрибутивов Linux’а или более иных систем, например, какого-либо представителя BSD-семейства или OpenSolaris.

А теперь — вперёд. Для начала размечаем системный диск. Первым создаём загрузочный раздел под каталог /boot — при использовании нескольких систем на одной машине предпочтительным загрузчиком будет GRUB, причём его желательно также изолировать от той ОС, средствами которой он будет установлен. Очевидно, что загрузочный раздел лучше сделать первичным, 100 Мбайт на него хватит за глаза.

Далее размечаем раздел под ту Linux-систему, которую планируется сделать основной. Для чего создаём логические разделы в extended partition — сначала под swap (при нынешних объемах памяти достаточно будет 1 Гбайт), затем под корень основной системы: в зависимости от дистрибутива, на это можно отвести 10-15 Гбайт, не заморачиваясь отдельными разделами под такие ветви файловой иерархии, как /var, /usr и так далее.

Далее возможны варианты. В том же расширенном разделе можно создать несколько разделов логических под эксперименты с различными дистрибутивами Linux’а (опять же в объёме 10-15 Гбайт каждый. А оставшееся пространство оставить неразмеченным на случай установки более иных систем, например, FreeBSD и OpenSolaris, каждая из которых потребует для себя первичного дискового раздела — а их у нас в резерве как раз два и останется. А можно отказаться от дополнительных логических разделов, оставив всё пространство сверх /boot, swap и / неразмеченным. И та, и другая схема имеют свои достоинства и недостатки, но вторая представляется более гибкой.

Таким образом мы расправились с меньшим и, в идеале, быстрым системным диском. Теперь переходим к диску ёмкому. На нём перво-наперво обособляем небольшой раздел под /home — 1 Гбайт будет более чем достаточно. Поскольку в нём не поланируется держать ничего, кроме пользовательских dot-файлов в каталогах /home/username1, /home/username2 и так далее: у меня в системе обычно существует два пользователя — один для работы, второй — для экспериментов. Но в случае домашней машины может потребоваться и больше аккаунтов — для чад и домочадцев.

Далее — раздел под рабочие данные, назовём его, например, /home/work, разделы под скачиваемые из сети софтины, под аудио- и видеофайлы — /home/soft, /home/audio и /home/video, соответственно. Все эти разделы (включая и /home) делаем логическими, а размер каждого определяется по потребностям и возможностям.

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

Теперь переходим к выбору файловых систем. Однозначен он только для раздела под /boot на первом диске: единственно осмысленным тут будет ext2. В отношении всех остальных — возможны варианты. Для меня, впрочем, в последнее время они сводятся к альтернативе между ext4 и btrfs — причём для всех созданных разделов. Первая несколько выигрывает в быстродействии (см. результаты последнего тестирования) и к тому же считается более… апробированной, что ли. Вторая же, подобно ZFS, поддерживает ряд функций управления логическими томами. Правда, насколько они востребованы именно в десктопных условиях, остаётся вопросом. В любом случае, и ext4, и btrfs позволяют избежать зоопарка файловых систем, неизбежного в иных случаях.

Если же оставаться в рамках традиционных файловых систем, то для корня файловой иерархии беспроигрышным вариантом с точки зрения надёжности и совместимости будет ext3, для /home и его подкаталогов, кроме /home/video, оправданно использование reiserfs. Что же до /home/video — здесь следует выбирать между той же reiserfs и XFS. Последняя считается специально предназначенной для хранения больших и очень больших файлов, однако во всём блеске проявляет себя лишь в многодисковых конфигурациях, в частности, на программном RAID0. А мы вроде раньше уже решили, что народу это не нужно.

А теперь самое время вспомнить о том самом первичном разделе на втором диске, для которого мы не определили точку монтирования. Он создан в предвидении экспериментов с операционками, отличными от Linux, и предназначен для обмена данными между ними. Ибо и FreeBSD, и, тем более, OpenSolaris либо вообще не воспринимают современных файловых систем, для Linux’а нативных, либо способны работать с ними в режиме только чтения. Так что для обмена данными с FreeBSD подойдёт единственно ext3 — судя по моему опыту, работа с ней в режиме чтения/записи вполне безопасна.

А вот OpenSolaris, похоже, кроме своих собственных UFS и ZFS (причём заметим, что это не совсем те же самые UFS и ZFS, что и во FreeBSD) способен воспринимать только FAT разного рода. Так что, возможно, именно на FAT32 и придётся остановить выбор для exchange-раздела — не смотря на все недостатки и осложнения такого варианта.

Теперь переходим к вопросам монтирования и его опций. Каталог /boot в случае использования GRUB’а разработчики последнего рекомендуют не монтировать автоматически, при старте системы, а только по мере надобности — например, при изменении конфигурации загрузчика или установке новых ядер. Это резонно, так как избавляет не только от случайных ошибок, но и от нарушения целостности файловой системы при сбоях, например, по питанию. Так что согласимся с этой рекомендацией.

Корень файловой системы, очевидно, должен монтироваться автоматически. Как и каталоги /home и все его подкаталоги. Очень полезной опцией для них всех (а для разделов на SSD, включая /boot, так просто необходимой) будет noatime, запрещающая обновление метаданных тех файлов, к которым происходило обращение: кроме повышения быстродействия (в случае с файловой системой reiserfs — заметного невооружённым глазом), она обеспечивает долголетие твердотельного накопителя.

В последнее время вместо опции noatime рекомендуется сходная опция — relatime. Ей отличие в том, что при ней атрибут времени доступа (atime) обновляется — но только в том случае, если изменились данные файла (атрибут mtime) или его статус (атрибут ctime). Поскольку и то, и другое в корневом каталоге (и в каталоге /boot) происходит не так уж часто, результат её действия будет практически тем же самым, что и при использовании опции noatime — с той только разницей, что она всё-таки даёт представление о реальном изменении файлов. Можно теоретически представить себе ситуацию, когда это будет способствовать безопасности — например, при тех самых гипотетических вирусных атаках, неизбежностью которых нас вот уже второй десяток лет пугают зачмонатые вирусами вендузяднеги.

Ну а exchange-раздел, ясное дело, в автоматическом монтировании не нуждается — его можно будет подмонтировать вручную по мере необходимости к файловой иерархии того или иного дистрибутива или ОС. Причём — от имени пользователя.

В результате всех указанных действий файл /etc/fstab основной Linux-системы должен приобрести (автоматически, после инсталляции, или после ручной правки) примерно следующий вид:

/dev/sda5	swap	sw	relatime		0	0

/dev/sda6	/	ext4	relatime,errors=remount-ro	0	1

/dev/sda1	/boot	ext2	noauto,relatime		0	2

/dev/sdb5	/home	ext4	relatime		0	2

/dev/sdb6	/home/work	ext4	relatime	0	2

/dev/sdb7	/home/soft	ext4	relatime	0	2

/dev/sdb8	/home/audio	ext4	relatime	0	2

/dev/sdb9	/home/video	ext4	relatime	0	2

/dev/sdb2	/home/mnt	ext3	noauto,user,relatime	0	2

Тут следует учитывать ещё такой момент: современные версии ряда дистрибутивов, таких, как Ubuntu с сородичами, Archlinux, возможно, другие, при автоматической генерации файла /etc/fstab во время установки оперируют уникальными идентификаторами устройств вместо их имён, в результате чего строки приобретают примерно такой вид:

# /boot was on /dev/sda1 during installation

UUID=UUID=10b9d12f-7737-4d27-ba8a-39b6013e57ea	/boot	ext2	relatime	0	2

Что имеет как очевидные недостатки (неудобочитаемость), так и преимущества: например, при переключении винчестера на другой разъём SATA или IDE нет необходимости в правке имён устройств. Впрочем, и внесение имён файлов устройств пока не возбраняется — возможен и смешанный формат строк. Это целесообразно в том случае, если существовавший раздел был уничтожен какой-либо утилитой дисковой разметки,, а затем создан заново — его уникальный идентификатор будет уже другим. Теоретически UUID любого устройства можно выудить из недр файловой системы sysfs (монтируемой в каталог /sys), однако практически это не очень тривиальная задача — вследствие рекурсивной зацикленности подкаталогов в /sys инструменты типа grep здесь не работают. Впрочем, к файловой системе sysfs я планирую вернуться.

Все описанные действия — разметку дисков на разделы, создание файловых систем на них и определение точек монтирования их в файловой иерархии, — обычно можно выполнить на стадии установки системы, либо стандартными утилитами типа cfdisk, либо встроенными средствами инсталлятора данного дистрибутива. Хотя все разделы, кроме корневого, загрузочного и подкачки можно будет создать и в последующем, вручную — тем же fdisk, cfdisk или parted (см. статью о дисковой разметке). После чего утилитами типа mkfs.ext#, mkfs.btrfs и так далее создать соответствующие файловые системы (как — примерно описано здесь) и прописать их точки монтирования в /etc/fstab).

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

$ ls -l /home alv

drwxr-xr-x 37 alv  alv   4096 2009-05-10 16:50 alv/

для Ubuntu и её сородичей. В большинстве же дистрибутивов Linux основная группа любого пользователя будет users, что и будет фигурировать в выводе команды ls -l.
Остальные же подкаталоги каталога /home, вне зависимости от способа их создания, окажутся принадлежащими root’у и его группе:

drwxr-xr-x  2 root root  4096 2009-05-06 11:10 work/

То есть запись в них для обычного пользователя будет запрещена. Что нас, разумеется, совершенно не устраивает — не для того мы эти каталоги создавали.

Самый простой способ дать возможность пользователю полноценно работать с этими каталогами — изменить атрибуты их принадлежности:

$ sudo chown -R alv:alv /home/*

в Ubuntu или

$ su

# chown -R alv:users /home/*

например, в Zenwalk’е.

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

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

Самый простой способ — это во всех вновь устанавливаемых дистрибутивах Linux’а создавать пользователя с тем же собственным и групповым идентификаторами, что и у главного пользователя основной системы. Подчёркиваю — не с тем же именем (имя как раз может быть и другим, во избежание путаницы), а с тем же численным идентификатором.

И тут надо быть внимательным — правила присвоения численного идентификатора вновь создаваемом у пользователю различны в разных дистрибутивах. Обычно нумерация пользователей начинается с 1000 или 1001, но в некоторых системах первый пользователь может получить номер 500 или 100.

Так что самое надёжное — это принудительно задавать uid и guid пользователя в новоустанавливаемых системах таким же, каким он был в системе основной. Благо большинство утилит для управления пользовательскими аккаунтами дают такую возможность.