Antergos и ZFS. Настройка файловых систем

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

Antergos. Содержание

Если при установке Antergos’а был выбран вариант с размещением его корня на пуле ZFS, то первое, чем хороши бы заняться после рестарта — это настройкой файловых систем внутри неё. Разве что сначала уделить некоторое время настройке командной оболочки (в нашем случае это будет Zsh), причём от root’а. И происходить всё будет в Страшной Чёрной Текстовой Консоли, которую тоже не помешает настроить.

Конечно, данное занятие можно отложить и на потом — но чем «потомее» им заняться, тем сложней его будет выполнить. А отказ от настройки файловых систем лишает занятие с ZFS всякого смысла. Тем более, что настройка выполняется несколькими несложными действиями и требует только последовательности и аккуратности — а в этом, как я неоднократно говорил, коту Manual’у не откажешь.

Итак, убедившись после первого рестарта, что всё установилось и работает, пероеходим в заблаговременно настроенную текстовую консоль (например, вторую — по комбинации Control+Alt)+F2). И авторизуемся в ней, оказавшись в командной оболочке Zsh, об установке и конфигурировании которой мы также позаботились.

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

$ sudo -i

В данной ситуации излюбленная нами форма sudo -s, видимо, не походит, хотя на практике мы проверять это не стали. После ввода пользовательского пароля приглашение Zsh приобретёт такой вид :

.-(~)-----------------------------(root@cintergos)-
`--# 

Обретя права root’а, можно очистки совести для просмотреть устройство пула ZFS:

# zpool status
  pool: zant
 state: ONLINE
  scan: none requested
config:

	NAME                                                 STATE     READ WRITE CKSUM
	zant                                                 ONLINE       0     0     0
	  ata-KINGSTON_SUV400S37120G_50026B7766047DDF-part2  ONLINE       0     0     0

errors: No known data errors

А после этого посмотреть на входящие в него наборах данных (datasets, в терминологии ZFS):

# zfs list
NAME             USED  AVAIL  REFER  MOUNTPOINT
zant             14,5G  93,0G  6,74G  /
zant/swap        7,22G   100G    72K  -

Как и следовало ожидать из сообщений в ходе инсталляции, в списке присутствует лишь одна файловая система, корневая. А выводе команды

# mount | grep zfs

можной увидеть атрибуты её монтирования:

zant on /mnt type zfs (rw,xattr,noacl)

И вот сейчас самое время переопределить некоторые из них — они будут унаследованы всеми дочерними файловыми системами.

Для начала полезно избавиться от атрибута atime — обновления времени доступа к файлам (в условиях десктопа оно обычно не только не полезно, но может быть и вредно):

# zfs set atime=off zant

Мы с котом не видим необходимости и в атрибуте xattr — избавиться от него можно аналогичным способом:

# zfs set xattr=off zant

После чего картина с аттрибутами будет выглядеть так:

# mount | grep zfs
zant on /mnt type zfs (rw,noatime,noxattr,noacl)

Хотя можно этого и не делать — xattr вроде ничему не мешает. Даже напротив, при желании можно включить и acl (поддержку списков контроля доступа):

# zfs set acl=on zant

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

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

$ tar xvf alv.tar.gz /mnt/home/alv

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

Затем мы просто удалили домашний каталог пользователя, чей аккаунт был создан при инсталляции:

# rm -R /mnt/home/alv

При этом каталог удалился молча, без всяких жалоб на то, что он используется каким-то процессами, запущенными пользователем alv — именно поэтому мы с котом и воспользовались опцией -i для обретения права root’а. Хотя что было бы при употреблении опции -s — проверять не стали.

Теперь препятствия для создания файловой системы, родительской для всех домашних каталогов, отпали:

# zfs create zant/home

А затем и всех вложенных в неё подкаталогов — для пользователя аккаунта, созданного при инсталляции:

# zfs create zant/home/alv

Для наших рабочих проектов:

# zfs create zant/home/proj

Для всякого рода мультимедии:

# zfs create zant/home/media

И, наконец, для кота Manual’а, персональный аккаунт которого будет создан в ближайшее время:

# zfs create zant/home/kot

Разумеется, первым трём каталогам были приданы должные атрибуты принадлежности:

# chown -R alv:users /home/alv /home/proj /home/media

Ну и кота не следовало обидеть в правах доступа к нашим с ним общим каталогам:

# chmod -R g+w /home/media /home/proj

Таким образом, у нас образовалось шесть «безразмерных» файловых систем, в чём легко убедиться:

# zfs list
NAME              USED  AVAIL  REFER  MOUNTPOINT
zant             14,5G  93,1G  6,75G  /
zant/home         516M  93,1G   104K  /home
zant/home/alv     363M  93,1G   363M  /home/alv
zant/home/kot      96K  93,1G    96K  /home/kot
zant/home/media    96K  93,1G    96K  /home/media
zant/home/proj    152M  93,1G   152M  /home/proj

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

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

Для разрешения этого противоречия мы решили присвоить файловой системе /home/proj резервирования:

# zfs set reservation=5G zant/home/proj

Аналогичную процедуру я, не смотря на протесты кота Manual’а, выполнил и для файловой системы под себя, любимого, только был чуть скромнее:

# zfs set reservation=1G zant/home/alv

И в после этого вывод команды

# zfs list

показывает, что доступное пространство для всех файловых систем убавилось, но по разному:

zant             20,0G  87,6G  6,75G  /
zant/home        6,00G  87,6G   104K  /home
zant/home/alv     364M  88,2G   364M  /home/alv
zant/home/kot      96K  87,6G    96K  /home/kot
zant/home/media    96K  87,6G    96K  /home/media
zant/home/proj    152M  92,4G   152M  /home/proj

То есть, как бы широко ни размахивалась мультимедия, 5 ГБ дискового пространства будут доступны только для файловой системы под проекты. А 1 гигабайт, что бы ни случилось, подобно Алексею Свиридову, преложителю известного стиха Профессора,

…я себе оставлю,
На пьянку и похмелье.

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

# zfs set copies=2 zant/home/proj

Контрольные суммы, сколько бы их не было, поддерживают целостность данных, но ни в коем случае не их сохранность. На этот предмет в ZFS предусмотрен механизм снапшотов. Однако к нему мы вернёмся позднее, когда у нас появится то, что нужно будет «снапшотить».

А пока мы временно расстаёмся с ZFS, и перезагружаем систему — до сих пор необходимости в этом не было, и пул ZFS, и её файловые системы подхватывались, как говорится, «с лёту». Домашний каталог пользователя alv, который перед рестартом был пуст, после него волшебным образом наполняется его прежним содержимым, включая, включая наш ~/.zshrc. Разумеется, потому, что при настройке Zsh мы с котом не забыли скопировать его в /etc/skel, из которого были восстановлены и все другие умолчальные конфиги. Так что архивирование домашнего каталога, о котором говорилось вначале, было чистой перестраховкой.

Теперь остаётся только добавить, что размещение корня файловой иерархии на ZFS отнюдь не препятствует монтированию в неё традиционных файловых систем. Одна из них (конкретно ext4) была смонтирована на в каталог /boot ещё на стадии инсталляции Antergos’а, который можно увидеть в файле /etc/fstab:

UUID=0a002004-1d99-4b96-9826-221a79a4b68e /boot ext4 defaults,noatime,discard,data=ordered 0 0

Нынче же нам с котом нужно было подмонтировать раздел одного SSD со всеми пользовательскими данными, нажитыми ранее непосильным трудом, и раздел HDD со всякой всячиной. Что и было выполнено внесением в него же таких строк:

UUID=c80773f1-602b-4c18-ad8c-031d7e4936f0 /home/data ext4 defaults,noatime,discard 0 2
UUID=2bfe1a13-978b-4b2f-8685-fd8102c7499d /home/back ext4 defaults,noatime 0 2

Разумеется, для них должны были быть созданы точки монтирования с определением должных атрибутов принадлежности и доступа. После чего команда

# mount -a

сделала указанные файловые системы, вместе с их содержимым, доступными в Antergos’е. И позволила нам с Manual’ом продолжить настроечные мероприятия. По завершении которых вернулись к ZFS на предмет её снапшотов.

Содержание

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