Обработка поведения снимков ZFS при изменении, перемещении и переименовании файлов

Question

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

1. Когда файл изменяется в ZFS после моментального снимка, будет ли моментальный снимок иметь тот же размер и только различия или весь файл?
2. Когда файл перемещается в ZFS после моментального снимка, останется ли моментальный снимок практически нулевого размера?
3. Когда файл переименовывается в ZFS после моментального снимка, останется ли моментальный снимок практически нулевого размера?

4. Если после моментального снимка файл имеет свою копию с жесткой ссылкой, будет ли этот снимок оставаться практически пустым?

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

6. Когда машина Windows получает доступ к общему ресурсу ZFS удаленно через SAMBA, будет ли выполняться то же поведение, что и выше, или SAMBA является подмножеством стандартных инструкций привода, т. Е. Перемещение становится копированием + удалением?

7. Можно ли дать ответы на вышеприведенные вопросы в целом или все ответы зависят от реализации?

По просьбе комментатора, ниже описан тест, описанный для описанных операций:

Системная информация:

• CentOS 7 ядро 3.10.0
• ZFS v0.6.5.9-1

,

                  `zpool list`           `zfs list`
      POOL        SIZE  ALLOC   FREE    USED   AVAIL  REFER

Создать пул: zpool create -m /test/mnt FILE-TEST /test/1.img /test/2.img

      FILE-TEST   224M  80.5K    224M    73K    192M    19K

Снимок: zfs snapshot FILE-TEST@1

      FILE-TEST   224M   122K    224M    73K    192M    19K
      FILE-TEST@1                          0       -    19K

Создать файл: echo ‘test’ > /test/mnt/test.txt

      FILE-TEST   224M   132K    224M    95K    192M    21K
      FILE-TEST@1                        17K       -    19K

Увеличьте размер файла: `head -c 128K /test/mnt/test.txt

      FILE-TEST   224M   678K   223M    490K    192M    148K
      FILE-TEST@1                        17K       -    19K

Снимок: zfs snapshot FILE-TEST@2

      FILE-TEST   224M   267K   224M    239K    192M    148K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                          0       -     48K

Редактировать файл, изменить последние 4 байта.

      FILE-TEST   224M  1.07M   223M    386K    192M    148K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K

Снимок: zfs snapshot FILE-TEST@3

      FILE-TEST   224M   548K   223M    388K    192M    148K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K
      FILE-TEST@3                          0       -    148K

Переименовать файл mv test.txt test2.txt

      FILE-TEST   224M   552K   223M    404K    192M    150K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K
      FILE-TEST@3                        10K       -    148K

Снимок: zfs snapshot FILE-TEST@4

      FILE-TEST   224M  1.06M   223M    645K    191M    150K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K
      FILE-TEST@3                        10K       -    148K
      FILE-TEST@4                          0       -    150K

Новая папка: mkdir /test/mnt/subdir

      FILE-TEST   224M   716K   223M    420K    192M    151K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K
      FILE-TEST@3                        10K       -    148K
      FILE-TEST@4                         9K       -    150K

Снимок: zfs snapshot FILE-TEST@5

      FILE-TEST   224M   790K   223M    424K    192M    151K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K
      FILE-TEST@3                        10K       -    148K
      FILE-TEST@4                         9K       -    150K
      FILE-TEST@5                          0       -    151K

Переместить файл: mv /test/mnt/test2.txt /test/mnt/subdir/

      FILE-TEST   224M   584K   223M    444K    192M    151K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K
      FILE-TEST@3                        10K       -    148K
      FILE-TEST@4                         9K       -    150K
      FILE-TEST@5                        10K       -    151K

Снимок: zfs snapshot FILE-TEST@6

      FILE-TEST   224M   602K   223M    447K    192M    151K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K
      FILE-TEST@3                        10K       -    148K
      FILE-TEST@4                         9K       -    150K
      FILE-TEST@5                        10K       -    151K
      FILE-TEST@6                          0       -    151K

Создать файл жесткой ссылки: cp -l /test/mnt/subdir/test2.txt /test/mnt/subdir/test3.txt

      FILE-TEST   224M   603K   223M    466K    192M    152K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K
      FILE-TEST@3                        10K       -    148K
      FILE-TEST@4                         9K       -    150K
      FILE-TEST@5                        10K       -    151K
      FILE-TEST@6                        12K       -    151K

Наблюдения из вышесказанного:

• РАЗМЕР и БЕСПЛАТНО очень постоянны и соответствуют занимаемому пространству файла (ов)
• ALLOC является случайным
• REFER на снимках, кажется, равен текущему значению REFER для пула
• В большинстве операций значение USED для снимков составляет около 10 КБ, за исключением изменения файла, в котором значение USED немного больше, чем весь измененный размер файла.
• ИСПОЛЬЗУЕТСЯ в бассейне растет в неравных прыжках
• REFER постепенно растет около 1K за операцию
• Нетекущие снимки остаются неизменными по размеру

Answer 1

1. Когда файл изменяется в ZFS после моментального снимка, будет ли моментальный снимок иметь тот же размер и только различия или весь файл?

Различные блоки увеличивают размер.

Это означает, что если файл состоит из 100 блоков и вы изменяете один байт (при условии, что один байт меньше одного блока), в конце будет добавлен один новый блок (всего 101), ваш старый файл будет ссылаться на блоки с 1 по 100 ( можно получить доступ только для чтения из моментального снимка), и ваш новый / текущий файл будет ссылаться на блоки с 1 по 37 и с 39 по 101 (или любую другую комбинацию в зависимости от вашей действительной операции модификации).

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

2. Когда файл перемещается в ZFS после моментального снимка, останется ли моментальный снимок практически нулевого размера?

Внутри той же файловой системы да, кроме метаданных (ссылки должны быть переставлены, например).

Между файловыми системами это операция полного копирования + удаления, даже если файловые системы находятся в одном пуле или являются потомками друг друга.

3. Когда файл переименовывается в ZFS после моментального снимка, останется ли моментальный снимок практически нулевого размера?

Да, помимо метаданных (например, ваше новое имя должно быть где-то записано).

4. Если после моментального снимка файл имеет свою копию с жесткой ссылкой, будет ли этот снимок оставаться практически пустым?

Не могли бы вы быть более конкретным здесь?

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

Я бы не предположил, что он делает все то же самое.

6. Когда машина Windows получает доступ к общему ресурсу ZFS удаленно через SAMBA, будет ли выполняться то же поведение, что и выше, или SAMBA является подмножеством стандартных инструкций привода, т. Е. Перемещение становится копированием + удалением?

У вас есть две возможные реализации для общего доступа к файлам Windows - либо сервер CIFS, разработанный Sun для Solaris и использующий OpenSolaris/illumos с открытым исходным кодом, либо реализация Samba SMB, которая используется почти во всех дистрибутивах GNU/Linux и системах BSD:

• Версия Solaris лучше адаптирована к функциям ZFS (например, установка свойств общего ресурса непосредственно в файловых системах, реализация снимков ZFS в качестве предыдущих версий Windows).
• С другой стороны, версия Samba является более кросс-платформенной и имеет некоторые более продвинутые функции, такие как (частичная) поддержка SMB3, IIRC.

Я предполагаю, что во втором случае у вас примерно так же, как на других системах, хотя я не проверял это.

7. Можно ли дать ответы на вышеприведенные вопросы в целом или все ответы зависят от реализации?

Вы можете ответить на него в соответствии с кодом, который есть в репозитории illumos/OpenZFS (репозиторий Github), если вам нравится читать код C, или вы можете ответить на него в целом в соответствии со справочными страницами и документацией. Например, свойства REFER, USED и т.д. Подробно описаны там. Наиболее интересными man-страницами являются man zpool (аппаратное обеспечение, разметка дисков, свойства пула), man zfs (свойства файловой системы, снимки, клоны), man chmod (только для Solaris/illumos, ACL для файлов и общих ресурсов ) и man zdb (отладка и анализ).