архив
Стратегия дисковой разметки
2009-05-13
О дисковой разметке в Unix-подобных (или POSIX-совместимых) операционных системах написано немало. Много копий было сломано в форумных обсуждениях того, насколько дробно следует размечать диск, каковы предпочтительные файловые системы в зависимости от назначения, какие опции форматирования и параметры монтирования следует задавать для отдельных ветвей файловой иерархии, выносимых на самостоятельные разделы. А также теоретическим вопросам — насколько практика разметки, форматирования монтирования согласуется с квази=законодательным документом — стандартом файловой иерархии (HFS — Filesystem Hierarchy Standard).
Изрядно сил и времени затратил на описание этих вопросов и автор настоящих строк. В частности, предложив некогда, в дополнение к оговоренному FHS обособлению каталогов на разделяемые и неразделяемые, с одной стороны, и неизменяемые и изменяемые — с другой, обособлять в первую очередь каталоги с легко восстановимым и трудно восстановимым контентом.
Ныне большая часть рекомендаций, ещё недавно казавшихся оправданными, представляется утратившими актуальность — как, впрочем, и сам HFS, отдающий глубокой архаикой. Тем более, что рекомендациям этого стандарта, кажется, не следует ни один из дистрибутивов Linux, не говоря уже о прочих POSIX-системах...
В силу всего сказанного рискну предложить ещё одну схему дисковой разметки и размещения на разделах файловых систем — ту, которая представляется мне наиболее адекватной нынешним условиям. И для начала подчеркну два момента:
- всё сказанное относится к настольному десктопу (или ноутбуку, выполняющему роль первой, а то и единственной, машины) конечного, в первую очередь домашнего, пользователя — ибо автор причисляет себя именно к этому сословию; для серверов или сетевых рабочих станций индустриального применения всё может быть иначе; также нет необходимости заботиться о сложной дисковой разметке для ноута или нетбука, играющего роль второй машины;
- предлагаемая схема рассчитана на применение, по крайней мере эпизодическое, более чем одного дистрибутива или операционной системы — ведь какой же линуксоид время от времени не устанавливает, в дополнение к основной рабочей системе ещё какой-либо дистрибутив или ОС в экспериментальных целях; причём нельзя исключить вероятности того, что экспериментальная система станет со временем основной.
Что же до повышения надёжности, обеспечиваемого, например, RAID-массивами с избыточностью, то в условиях настольного десктопа оно также кажущееся: вряд ли у кого из "домашних" пользователей в ящике стола валяется без дела запасной винчестер, которым можно заменить вышедший из строя компонент массива. А буде таковой и имеется — проще и надёжней прикрутить его в качестве резервного хранилища, заполняемого вручную или в полуавтоматическом режиме, посредством какой-либо-cron-подобной утилиты.
С другой стороны, любого рода многодисковые объединения создают изрядные сложности при реконфигурировании машины — как аппаратном, так и программном. А ведь замена, добавление или удаление дисков из домашней машины происходит не так уж редко.
Это одна сторона "железного" вопроса. Другая же — не за горами массовое внедрение SSD-накопителей, по крайней мере, в качестве системных: как замена больших хранилищ данных они не скоро ещё станут конкурентоспособны относительно традиционных винчестеров (если когда-нибудь станут вообще).
В связи с этим для настольной машины мне ныне представляется двухдисковая конфигурация: с диском быстрым (aka системным) и диском ёмким (сиречь хранилищем данных). Впрочем, как оказалось, не я первый это придумал: аналогичные рекомендации можно найти во всех недавних обзорах накопителей на всенародно любимом Хоботе.
Для ноутбука подобные рекомендации выполнить довольно трудно — разве что в качестве хранилища данных использовать внешний винчестер с интерфейсом eSATA, но машины с этим разъёмом пока довольно редки.
А вот для нетбуков, как это ни парадоксально, указанную конфигурацию собрать достаточно легко: можно найти модель с небольшим SSD-накопителем и прикрутить к ней всё тот же внешний винчестер. Правда, нетбуков с eSATA я пока не видел — но думаю, их появление не за горами.
Теперь о принципах разметки. Их два:
- обособить системную часть от пользовательских dot-файлов, с одной стороны, и от собственно данных — с другой;
- обеспечить доступ к пользовательским данным из различных дистрибутивов Linux'а или более иных систем, например, какого-либо представителя BSD-семейства или OpenSolaris.
Далее размечаем раздел под ту 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Тут следует учитывать ещё такой момент: современные версии ряда дистрибутивов, таких, как Ubuntu с сородичами, Archlinux, возможно, другие, при автоматической генерации файла /etc/fstab во время установки оперируют уникальными идентификаторами устройств вместо их имён, в результате чего строки приобретают примерно такой вид:/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
# /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 пользователя в новоустанавливаемых системах таким же, каким он был в системе основной. Благо большинство утилит для управления пользовательскими аккаунтами дают такую возможность.