Cintu после установки: подключение дополнительных разделов

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

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

Вступление

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

Условия автоматического монтирования файловых систем при старте машины описываются в одном из ключевых конфигурационных файлов любой UNIX-подобной системы, в том числе и любого Linux’а. Файл этот — /etc/fstab, и представляет собой очень простую базу данных, содержащую такие поля, разделяемые пробелами или табуляцией:

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

Сразу после установки Cintu посредством инсталлятора из Systemback файл /etc/fstab выглядит следующим образом:

# <file system> <mount point> <type> <options> <dump> <pass>
# /     /dev/sda1
UUID=[бла-бла]   /   ext4   errors=remount-ro   0   1

Здесь UUID (Universally Unique IDentifier) — один из видов поддерживаемых идентификаторов устройств, в том числе блочных (то есть дисков и их разделов), значением которого является зубодробительная последовательно алфавитно-цифровых символов. Например, у меня он выглядит так:

UUID=bf6a6e6e-9678-4a21-ab48-a44d51bc0a87

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

Так что, если требуется подключить существующий раздел с какой-либо Linux’овой файловой системой и данными на ней, достаточно создать ещё одну запись в файле /etc/fstab по образу и подобию существующей.

Правка умолчаний «корня»

Первый шаг в решении поставленной задачи — открытие с правами администратора нужного нам файла. Например, в терминале это можно сделать так:

$ sudo nano /etc/fstab

А в графическом режиме — чуть иначе: комбинацией клавиш Alt+F2 вызвать командную строку минитерминала и набрать в ней

gksu leafpad /etc/fstab

after-install_001

Почему в разных случаях для обретения прав администратора используются разные команды — будет сказано со временем. Пока же важно, что в обоих случаях потребуется ввод пользовательского пароля, после чего требуемый файл будет открыт — или в редакторе Nano в окне терминала, либо в собственном окне редактора Leafpad. И остаётся только добавить в него запись со всеми заполненными полями.

Однако прежде можно проделать с имеющейся по умолчанию записью пару манипуляций. Например, я всегда добавляю в список опций её монтирования такую, как noatime, запрещающую обновлять время последнего доступа (так называемое Access Time) к файлам и каталогам. На настольной машине оно не требуется (почти?) никогда, но слегка снижает быстродействие и, вероятно, чуть-чуть повышает износ накопителей, особенно SSD.

Тут надо сделать несколько замечаний. Во-первых, часто можно наткнуться на предложение добавить также опцию nodiratime — как нетрудно догадаться, она запрещает обновление Access Time для каталогов (и только для них). Однако при использовании опции noatime это делать не только не обязательно, но и не нужно: каталоги являются одним из типов файлов, а потому действие noatime распространяется и на них.

Во-вторых, столь же часто предложение вместо noatime использовать опцию relatime, как более «прогрессивную»: при ней Access Time обновляется только в том случае, если обновились время модификации файла или его статуса. В десктопных условиях это, опять же, излишество: реально знание времени доступа необходимо лишь при использовании некоторых программ (например, консольных почтовых клиентов), в нынешней жизни «настольного применителя» применяемых достаточно редко. А вот снижению производительности дисковых операций и износу накопителей она способствует, хотя и не столь «хорошо», как умолчальная опция atime, что полностью гасится нашей noatime.

Наконец, в-третьих: в ядре Linux, начиная с версии 4.0, поддерживается опция монтирования lazytime, которая также обеспечивает доступ к Access Time в необходимых случаях (то есть при изменении данных файла или его атрибутов), но делает это не столь «накладно», как relatime. Однако, подобно последней, и она нужна лишь редких ситуациях. И те, кому она реально необходима, сами знаю, в каких.

Для корневого (да и любого другого) раздела на SSD полезной считается опция discard — конечно, для тех файловых систем, в которых она поддерживается (из нативных Linux’овых это, кроме ext4, ещё и btrfs). Вдаваться в обсуждение её реальной нужности я здесь не буду, при современном развитии печатного дела контроллеров SSD-накопителей это вопрос спорный. Однако вреда от неё, вроде бы, нет, тогда как польза — возможна, так что добавить её — не грех. В результате редактируемая строка приобретёт вид:

UUID=[бла-бла]   /   ext4   noatime,discard,errors=remount-ro   0   1

На котором можно и успокоиться.

Файловые системы «постоянной готовности»

Ну а теперь — собственно об автоматическом монтировании раздела, несущего файловую систему с пользовательскими данными. Рассмотрим модельную, но весьма распространённую, ситуацию: имеется единственный диск с двумя разделами, /dev/sda1 и /dev/sda2. На первый средствами Systemback’а была установлена Cintu (или любой другой дистрибутив Linux, использующий тот же комплект для создания образов и инсталляции с них системы, например, Matuntu), на втором имеется файловая система с пользовательскими данными, постоянный доступ необходим позарез.

Собственно, некоторых комментариев требует только первое поле — имя или идентификатор раздела. Здесь можно использовать так называемое имя первого уровня — то есть, в нашем примере, /dev/sda2. Однако в Ubuntu и всех её производных принято, как уже было сказано, использование UUID. Не вдаваясь в обсуждение вопроса, хорошо это или плохо (он лежит далеко за рамками поставленной задачи и подробно рассмотрен в соответствующем очерке), просто последуем традиции. Для чего нужно этот самый UUID определить.

Как обычно, сделать это можно более чем одним способом. Первый — использование специально предназначенной для этого команды:

$ sudo blkid /dev/sda2

которая выведет нечто вроде этого:

/dev/sda2: UUID="0bbc88c4-8d12-4065-9483-6a8029f3257c" TYPE="ext4" PARTUUID="000c5e9f-02"

Легко догадаться, что именно значение UUID (но без кавычек!) и нужно вписать в первое поле нужной строки.

Второй способ не требует ни запоминания специальной команды, ни даже прав администратора (необходимых для выполнения blkid). Ибо все UUID’ы — не более чем символические ссылки на имена блочных устройств первого уровня, и их можно просомтреть непосредственно:

$ ls /dev/disk/by-uuid 

А с помощью команды

$ ls -l /dev/disk/by-uuid | grep sda2

легко определить, какой из UUID’ов соответствует нужному нам файлу устройства:

lrwxrwxrwx 1 root root 10 май 12 17:17 0bbc88c4-8d12-4065-9483-6a8029f3257c -> ../../sda2

Во второе поле вписывается имя каталога (с указанием полного пути), в который будет монтироваться файловая система — например, я для хранения пользовательских данных, доступных из всех моих систем (иногда весьма многочисленных), использую каталог /home/data (почему — отдельный вопрос). Каковой, разумеется, должен быть создан заблаговременно:

$ sudo mkdir /home/data

Третье поле — тип файловой системы, в которой был некогда отформатирован раздел — в моём случае это также ext4. Однако никто не запрещает подсоединить тем же образом раздел с любой другой ранее созданной файловой системой, например, xfs или reiserfs, вписав туда соответствующее имя.

В поле опций монтирования достаточно ограничиться значениями noatime,discard. Впрочем, последнее, как уже говорилось, применяется только для SSD-накопителей, а также не поддерживается файловыми системами XFS и ReiserFS.

Наконец, для двух последних полей есть смысл проставить умолчальные нули, хотя для поля pass иногда рекомендуется «двойка». Почему — опять же обсуждать не буду, но реально применитель обычно ни малейшей разницы не заметит. Так что итоговый вид новой записи в /etc/fstab будет примерно следующим:

UUID=[бла-бла]   /home/data   ext4   noatime,discard   0   0

Тем же самым образом можно обеспечить и монтирование какого-либо иного раздела, например, с коллекцией всякой парнухи мультимедии — вот здесь целесообразно использовать XFS:

UUID=[другое-бла-бла]   /home/media   xfs   noatime   0   0

В принципе, точно так же можно обеспечить и автоматическое монтирование носителей с какой-либо «чуждой» файловой системой, вроде NTFS, но практически это мне не понадобилось ни разу в жизни.

Применение изменений

Изменения, сделанные в /etc/fstab, вступят в силу после перезагрузки системы. Или после команды

$ sudo mount -a

Предварительно, разумеется, не забыв создать все прописанные в /etc/fstab точки монтирования — ы приведённом примере командой

$ sudo mkdir /home/media

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

Задействование tmpfs

Наконец, возможно, полезной окажется ещё одна, опциональная, запись в /etc/fstab:

tmpfs	/tmp	tmpfs	noatime	0 0

Она монтирует в каталог /tmp, предназначенный для хранения временных файлов, файловой системы в оперативной памяти, которая так и называется — tmpfs. Размер её по умолчанию равен половине наличной памяти, однако его можно задать и явным образом, большим или меньшим, указав это в качестве опции монтирования size=## (в любых *байтах или процентах RAM). В любом случае, оперативная память не резервируется под tmpfs, а задействуется по мере надобности. Кроме того, в целях безопасности для tmpfs рекомендуются опции, запрещающие исполнение в ней файлов, присвоения им бита suid’ности и размещения файлов устройств. Так что «по науке» приведённая выше строка должна выглядеть примерно так:

tmpfs	/tmp	tmpfs	noatime,noexec,nodev,nosuid,size=##g	0 0

После этого для задействования tmpfs желательна перезагрузка системы: за время сеанса в /tmp, ещё расположенной на диске, скапливается достаточное количество «хлама», который теоретически должен исчезнуть при рестарте.

Должен предупредить, что использование tmpfs для монтирования в каталог /tmp считается достаточно спорным. С одной стороны, выгоды такого решения очевидны: повышение быстродействия (хотя нынче и практически незаметное), снижение износа накопителя, гарантия очистки /tmp от «продуктов жизнедеятельности» при рестарте системы. Недостатков же его два. Во-первых, в последнее время оно весьма не рекомендуется разработчиками большинства дистрибутивов. Хотя внятных объяснений такой «нерекомендабельности» в общем случае я не нашёл, за исключением невнятных указаний на некую «возможную нестабильность». С которой, впрочем, тоже не сталкивался.

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

Автор этих строк всегда считал, что, вопреки мнению некогда знаменитой Нины Андреевой, нет таких принципов (и, тем более, догм), которые не заслуживали бы того, чтобы ими поступились в интересах дела. И потому всегда включал монтирование tmpfs в каталог /tmp описанным только что способом. За исключением тех случаев, когда банально забывал это сделать. Как, например, забыл при первичной настройке системы, в которой сочиняет эти строки — и проделал это только сейчас. Так что возможность легко забыть про такую хорошую штуку, как tmpfs — её второй (и, на мой взгляд, главный) недостаток…

Добавить комментарий