Читать онлайн «Linux Mint и его Cinnamon. Очерки применителя». Страница 90

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

pool: data

state: ONLINE

scan: none requested

config:

NAME        STATE     READ WRITE CKSUM

mypool      ONLINE       0     0     0

sdd       ONLINE       0     0     0

sdf       ONLINE       0     0     0

errors: No known data errors

А с помощью субкоманды list можно узнать объём новообразованного пула:

# zpool list data

NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT

data  18,9G    93K  18,9G     0%  1.00x  ONLINE  -

Легко видеть, что он равен сумме объёмов обеих флэшек, если «маркетинговые» гигабайты пересчитать в «настоящие».

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

# zpool list

NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT

exp   18,9G    93K  18,9G     0%  1.00x  ONLINE  -

data  199G  20,8G   178G    10%  1.00x  ONLINE  -

Обращаю внимание, что даже чисто информационные субкоманды вроде list и status требуют прав администратора.

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

# zpool destroy exp

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

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

# zpool create -f exp2 mirror sdf sdg

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

# zpool list mypool

NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT

exp2  3,72G  91,5K  3,72G     0%  1.00x  ONLINE  -

При различии объёмов больший диск будет «обрезан» до объёма меньшего.

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

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

# zpool create exp3 raidz sdd sdf sdg

что даст нам следующую картину:

# zpool list exp3

NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT

exp3  11,1G   205K  11,1G     0%  1.00x  ONLINE  -

Впрочем, как мне кажется, в настольных условиях не стоит выделки и эта овчинка.

И, наконец, последний вариант организации пула из более чем одного устройства — создание пула с кэшированием. Для чего создаём из двух устройств простой пул без избыточности и подсоединяем к нему устройство для кэша:

# zpool create exp4 sdd sdf cache sdg

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

# zpool list exp4

NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT

exp4  18,9G    82K  18,9G     0%  1.00x  ONLINE  -

где никаких следов его обнаружить не удаётся. Если же появляются сомнения, а подключилось ли оно на самом деле, обращаемся к субкоманде status, которая покажет беспочвенность наших опасений.

Как я уже говорил в обзоре возможностей ZFS, подключение устройства кэширования имеет смысл при наличии большого традиционного винчестера (или винчестеров) и относительно небольшого SSD, которое и играет роль дискового кэша.

Команда zpool поддерживает ещё множество субкоманд, предназначенных для экспорта и импорта пула, добавления к нему устройств и изъятия оных, и так далее. Но сейчас я расскажу о некоторых опциях, которые могут оказаться необходимыми при создании пула.

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

Полезной может оказаться опция -n. Она определяет тестовый режим выполнения определённой субкоманды, то есть выводит результат, например, субкоманды zpool create без фактического создания пула. И, соответственно, сообщает об ошибках, если таковые имеются.

Интересна также опция -m mountpoint. Как уже говорилось, при создании пула по умолчанию в корне файловой иерархии создаётся каталог /pool_name, который в дальнейшем будет точкой монтирования файловых систем ZFS. Возможно, что это окажется не самым лучшим местом для их размещёния, и, как мы увидим в дальнейшем, это несложно будет изменить. Но можно задать каталог для пула сразу — например, /home/data: это и будет значением опции -m. Никто не запрещает определить в качестве такового и какой-либо из существующих каталогов, если он пуст, иначе автоматическое монтирование файловых систем пула в него окажется невозможным.

Наконец, нынче важное значение приобретает опция ashift=#, значением которой является размер блока файловой системы в виде степеней двойки. По умолчанию при создании пула размер блока определяется автоматически, и до некоторого времени это было оптимально. Однако затем, с одной стороны, появились диски так называемого Advanced Format, в других размер блока равен 4 КБ. С другой стороны, получили распространение SSD-накопители, обычно также имеющие четырёхкилобайтный блок. В этих условиях автоматика ZFS может работать некорректно, что приводит к падению производительности пула.

Для предотвращения означенного безобразия и была придумана опция ashift. Значение её по умолчанию — 0, что соответствует автоматическому определению размера блока. Прочие же возможные значения лежат в диапазоне от 9 для блока в 512 байт (29 = 512) до 16 для 64-килобайтного блока (216 = 65536). В интересующем нас случае четырёхкилобайтного блока оно составляет 12 (212 = 4096). Именно последнее значение и следует указать явным образом при создании пула из винчестеров AF или большинства SSD-накопителей.

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

Для создания файловых систем предназначена субкоманда create команды zfs, которая требует единственного аргумента — имени создаваемой ФС и обычно не нуждается ни в каких опциях:

# zfs create pool_name/fs_name

Внутри пула можно создавать сколь угодно сложную иерархию файловых систем. Единственное условие — родительская файловая система для системы более глубокого уровня вложенности должна быть создана заблаговременно. Ниже я покажу это на конкретном примере создания файловых систем внутри каталога /home — наиболее оправданное место для размещёния наборов данных ZFS.

Начну я немножечко издалека. При стандартной установке Mint не обойтись без создания учетной записи обычного пользователя, и, следовательно, в каталоге /home будет присутствовать по крайней мере один подкаталог — /home/username.

Смонтировать же файловую систему ZFS в непустой каталог невозможно, и, значит, мы не можем сразу прибегнуть к опции -m для определения «постоянной прописки» создаваемого пула.

Поэтому для начала делаем для пула «прописку» во временной точке — пусть это будет традиционный /tank:

# zpool create -o ashift=12 tank ata-SanDisk_SDSSDX120GG25_120823400863-part3 ata-SanDisk_SDSSDX120GG25_120823402786-part3

Теперь создаём файловую систему для будущего домашнего каталога:

# zfs create tank/home

А внутри же неё — необходимые дочерние ветви, как то:

# zfs create tank/home/alv

которая потом заменит мой домашний каталог — в нём я не держу ничего, кроме конфигурационных файлов;

# zfs create tank/home/proj

это файловая система для моих текущих проектов, и так далее.

Как и было обещано разработчиками ZFS, процедура ничуть не сложнее, чем создание обычных каталогов. Благодаря этому файловые системы можно легко создавать по мере надобности, для решения какой-либо частной задачи. И столь же легко уничтожать их, когда задача эта выполнена. Что делается таким образом:

# zfs destroy pool_name/fs_name

Использовать субкоманду destroy следует аккуратно: никакого запроса на подтверждение при этом не будет. Правда, и уничтожить файловую систему, занятую в каком-либо текущем процессе, можно только с указанием опции -f, а файловую систему, содержащую системы дочерние, не получится убить и таким образом.

Ни в какой специальной операции монтирования новообразованные файловые системы не нуждаются — оно происходит автоматически в момент их создания, о чём свидетельствует следующая команда: $ mount | grep tank tank/home on /tank/home type zfs (rw,atime,xattr) tank/home/alv on /tank/home/alv type zfs (rw,atime,xattr) tank/home/proj on /tank/home/proj type zfs (rw,atime,xattr) ...