Концепция, устройство и администрирование файловой системы ZFS

Тип данных в блоке

Поле типа данных в указателе блока показывает, какой тип данных хранится в этом блоке. Типов немало, и они перечислены в таблице 8.6.

Уровень (lvl)

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

Счетчик заполненных блоков (fill count)

Счетчик заполненных блоков содержит количество ненулевых блоков под данным указателем блоков (т.е. на более нижних уровнях дерева блоков). Это поле равно 1 для указателя на блок данных, так как он не имеет ни одного указателя блоков ниже себя. Это поле имеет иное значение для указателя блоков типа DMU_OT_DNODE: для таких блоков поле содержит количество свободных дескрипторов ниже этого указателя блоков.

Номер породившей блок группы транзакций (birth txg)

64-битное целое поле birth txg (birth transaction) содержит номер группы транзакций, в ходе которой данный блок был занят под информацию.

Заполнители (padding)

Три блока-заполнителя в указателе блоков зарезервированы для использования в будущем.

Копирование при записи данных в ZFS (copy on write)

Предположим, что у нас есть некое дерево блоков ( рис. 8.1). Файловые системы традиционно представляют как дерево блоков. Любой блок данных в такой файловой системе можно найти, пройдя по ссылкам на дочерние блоки в направлении от корневого. Дерево на рисунке похоже на двоичное, но на самом деле дерево метаданных и данных в ZFS не является таковым: оно более широкое и менее глубокое.

Количество уровней в дереве блоков никак не соотносится с количеством уровней вложенных каталогов в файловой системе.

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

Пришла пора перезаписывать метаданные, а именно блоки прямой и косвенной адресации, которые должны указывать на наши новые блоки. Для этого записывают новые блоки адресации, а старые остаются такими же, как и раньше. Это показано в нижней левой части рис. 8.1.

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

Для того, чтобы завершить операцию записи новых данных, требуется перевести файловую систему из первоначального в измененное состояние (это показано справа внизу на рис. 8.1). Для этого надо перезаписать всего один блок, а именно – uber-блок. Эта операция является атомарной, поскольку при ее выполнении записывается ровно один блок на диске: ведь на диск на физическом уровне нельзя записать данные размером меньше блока.

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

Как только uber-блок записан, группа транзакций считается завершенной и файловая система оказывается в новом, тоже самосогласованном состоянии.

Снимки и резервное копирование

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

Функциональность снимков файловой системы (snapshot) дает возможность зафиксировать состояние всей файловой системы на определенный момент времени (причем гарантировано – все файлы фиксируются в том виде, в котором они существовали в ту конкретную наносекунду, когда вы потребовали сделать snapshot).

А чему радоваться разработчику? Да это же настоящая находка: не надо никаких средств архивирования версий; достаточно создать по мгновенному снимку на каждую версию разрабатываемой программы и двигаться дальше. Все версии ваших файлов будут сохранены автоматически.

Разумеется, снимки требуют места на диске – за функциональность приходится платить. Но так как снимок не требует копирования всех файлов (фактически новое место требуется только под измененные после "фотографирования" файлы), то и накладные расходы куда меньше, чем при резервном копировании всей файловой системы на соседний диск или ленту. Плюс к тому, снимок создается мгновенно, никакой траты времени на перезаписывание гигабайтов данных нет.

Сделать снимок файловой системы проще простого: он создается при помощи команды zfs snapshot, которой следует указать имя создаваемого снимка. Имя снимка указывается как filesystem @snapname:

# zfs snapshot pool/home/ahrens@friday

Здесь friday – имя снимка файловой системы pool/home/ahrens.

Создать снимки всех подчиненных файловых систем можно при помощи ключа -r.

Снимки можно использовать для резервного копирования; и – внимание! – все это на лету, без перехода в однопользовательский режим, в том числе – с версии Solaris Express build 62 – и для корневой файловой системы!

Как же это устроено внутри файловой системы? Что происходит при создании снимка?

Как видно из рис. 8.1, при перезаписи файла блоки с его старым содержимым остаются неизменными. Ничто не мешает в любой момент потребовать от системы сохранить старое состояние всего дерева блоков файловой системы, включая метаданные. Более того, снимок занимает мало места, так как данные, которые не изменялись с момента создания снимка, попросту являются общими и для рабочей файловой системы, и для снимка.

Кроме снимков можно создавать клоны файловой системы – снимки с возможностью записи в них. Когда в любом из клонов изменяются данные, новые блоки оказываются своими для каждого из клонов, но неизмененые данные хранятся в блоках, общих для всех клонов.