Глава 6. Управление дисковым пространством

# zfs list
NAME                 USED  AVAIL  REFER  MOUNTPOINT
zroot               17.5G   874G   144K  none
zroot/ROOT          1.35G   874G   144K  none
zroot/ROOT/default  1.35G   874G  1.35G  /
zroot/usr           12.5G   874G   454M  /usr
zroot/usr/local     1.84G   874G  1.84G  /usr/local
...
	   

Объем данных, содержащийся в наборе данных является ссылочными данными. Взглянем на колонку REFER в приведенном выше листинге. Пул zroot и zroot/ROOT оба ссылаются на 144КБ пространства. Будет достаточно грубо сказать: "да, днаая часть наполнения имеется". Это заполнитель. Набор данных zroot/ROOT/default, однако, ссылается на 1.35ГБ данных.

Ссылочные данные являются веществом, которое существует в пределах данной файловой системы или набора данных. Если вы перейдете в файловую систему zroot/ROOT/default, вы найдете 1.35ГБ наполнения.

То есть, мы складываем ссылочное пространство и получаем используемый объем? Нет, опять не так. Множество наборов данных ZFS могут ссылаться на один и тот же набор данных. Именно так работают снимки и клоны. Вот почему, например, несколько 10ГБ снимков размещаются в 11ГБ пространства.

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

А помимо этого еще существуют вопросы, связанные с освобождением пространства.

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

В файловой системе, применяющей снимки и клоны, недавно освобожденное пространство не возвращается немедленно. Многие операции ZFS освобождают пространство в асинхронном режиме по мере того, как ZFS обновляет все блоки, которые ссылаются на это пространство. Свойство пула freeing показывает сколько пространства ZFS нуждается в возвращении из данного пула. Если вы освобождаете за раз целую кучу пространства, вы можете заметить, что свойство freeing уменьшится и свободное пространство возрастет. Как быстро ZFS возвратит пространство зависит от вашего оборудования, объема нагрузки, архитектуры пула, уровня фрагментации и того, как используется пространство. {Прим. пер.: подробнее см. Освобождение блоков в переводе Главы 10. ZFS: Зеттабайт файловая система 2й редакции книги Маршала Кирка МакКузика, Джорджа В. Невил-Нейла и Роберта Н.М. Ватсона "Архитектура и реализация операционной системы FreeBSD" (ISBN-13: 978-0-321-96897-5)}.

Асинхронное освобождение пространства легко понять: вы наблюдаете за свойством freeing и видите как быстро оно уменьшается. Однако для непосвященных использование диска ZFS может показаться более странным. Допустим, у вас есть ряд снимков набора данных и их родительский набор данных переполняется. (Мы рассмотрим снимки в Главе 7, потерпите с нами сейчас.) Вы удалили череду больших ISO из этого набора данных. Удаление этих файлов не освободило никакого пространства. Почему?

Данные файлы ISO все еще существуют в ваших более старых снимках. ZFS знает, что эти файлы не существуют в текущем наборе данных, однако, если вы просмотрите каталоги снимков вы увидите эти файлы. ZFS должна хранить копии этих удаленных файлов для более старых снимков до тех пор, пока снимки ссылаются на эти данные. Содержимое снимков доступно только для чтения, следовательно единственный способ удалить эти большие файлы заключается в удалении этих снимков. Если у вас имеется множество снимков, использование диска становится более сложным. А клоны (Глава 7), строящиеся на снимках, ведут себя подобным образом.

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

# zfs list zroot
NAME    USED  AVAIL  REFER  MOUNTPOINT
zroot  37.7G   854G   144K  none
	   

Таким образом, ZFS имеет все мыслимые виды "нарезки на кубики и ломтики" (slice and dice) своих отображений использования диска. После десятилетий применения df(1) для просмотра использования диска многие из нас не хотят ничего менять. Однако, когда вы применяете ZFS, почтенный df(1) и многие другие инструменты являются не просто не оптимальны - они просто активно неверны и дают неправильные или противоречивые ответы для ZFS. Мы собираемся в качестве примера использовать df(1), но и многие другие инструменты имеют аналогичные проблемы.

Традиционные файловые системы состоят из одного раздела. Этот раздел имеет размер, основанный на выделенном на диске количестве блоков. Инструмент df(1) перебирает все смонтированные файловые системы и отобразит размер раздела, объем используемого в настоящее время пространства, а также сколько свободного пространства осталось.

Для ZFS проход по файловым системам не работает, поскольку наборы данных не являются файловыми системами. ZFS предоставляет каждый набор данных для операционной системы как если бы он был отдельной файловой системой. Набор данных не имеет максимального размера (если он не имеет квот). Хотя вы и можете установить верхние и нижние пределы на размер набора данных, все наборы данных ZFS имеют доступ ко всему доступному свободному пространству в пуле.

Чтобы предложить некое подобие совместимости с традиционным инструментом df(1), ZFS сообщает невинную ложь. Поскольку набор данных ZFS не имеет "размер" в понимании традиционной файловой системы, она суммирует используемое пространство и все доступное свободное пространство пула вместе и представляет это значение как "размер" этого набора данных.

Посмотрите на примеры пулов в предыдущем разделе. Набор данных zroot/ROOT/default использует 1.35ГБ пространства и имеет 874ГБ свободными. Общий размер составляет 873.35ГБ. Затем рассмотрим наш набор данных zroot/usr. Он потребляет 12.5ГБ и имеет 874ГБ свободными, в общей сложности 886.5ГБ.

Теперь проверим некоторые реальные выводы df(1) для этих наборов данных.

# df -h
Filesystem          Size  Used  Avail  Capacity  Mounted on
zroot/ROOT/default  875G  1.4G  874G         0%  /
zroot/usr           874G  454M  874G         0%  /usr
...
	   

Корневая файловая система занимает 875ГБ, а /usr составляет 874ГБ, давая в сумме для двух разделов 1749ГБ с 1748ГБ свободными. Довольно внушительно для диска 1ТБ, не так ли? Колонка "Capacity", которая отображает какой процент файловой системы используется, очевидно, фиктивен.

По мере роста наборов данных, объем свободного пространства сжимается. Согласно df(1), файловая система сжимается в размере по мере использования и растет при освобождении.

Такие инструменты как df(1) и большинство других инструментов мониторинга, предназначенных для традиционных файловых систем, дают неверные ответы. Остерегайтесь их! Хотя они могут показаться нормальными для быстрой проверки, продолжение применения этих инструментов зафиксирует вредные привычки. Вредные привычки системного администрирования приведут к головной боли и простоям. При наблюдении за свободным пространством набора данных убедитесь что вы измеряете действительный объем свободного, а не процент использования. Если традиционные инструменты, которые отображают "проценты использования" дают значимый результат, это простая случайность. Вашим системам наблюдения нужны инструменты, предназначенные для ZFS.

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

При применении ZFS выработайте привычку управлять ею при помощи точных инструментов.

# zfs list
NAME              USED  AVAIL  REFER  MOUNTPOINT
zroot/usr        12.5G   874G   454M  /usr
zroot/usr/local  1.84G   874G  1.84G  /usr/local
zroot/usr/obj    6.89G   874G  6.89G  /usr/obj
zroot/usr/ports  1.97G   874G   816M  /usr/ports
...
	   

Вы можете проверить refreservation и reservation по отдельности, но мы предпочитаем получить всю информацию о предварительном выделении за один раз. Вы можете просмотреть список определенных свойств выполнив zfs get -o reservation,refreservation,usedbyrefreservation, однако Лукас чрезвычайно ленив набирать их все, а к тому же он ведущий автор, поэтому данный пример использует grep(1).

# zfs get all zroot/var/log/db | grep reserv
zroot/var/log/db  reservation           none  default
zroot/var/log/db  refreservation        none  default
zroot/var/log/db  usedbyrefreservation  0     -
	   

Набор данных не имеет ни refreservation, ни reservation. Давайте что-нибудь установим.

Свойство usedbyrefreservation показывает, сколько пространства будет освобождено в этом наборе данных, если были удалены refreservation.

Установка предварительного выделения в точности аналогична вашим действиям с другими свойствами ZFS. Здесь мы устанавливаем refreservation для /var/log/db и reservation для /var/log.

# zfs set refreservation=10G zroot/var/log/db
# zfs set reservation=20G zroot/var/log
	   

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

Для удаления выделения установите его в none.

# zfs set reservation=none zroot/var/log
	   

Теперь другие наборы данных могут использовать это пространство.

Применяйте квоты всякий раз, когда вы хотите установить максимальный объем пространства, который может потреблять набор данных. Например, вы можете решить, что /tmp может использовать только 10ГБ, или что /home может брать только 200ГБ, или еще какие-то пределы могут быть существенны для вас.

Как и для предварительного выделения, ZFS применяет два свойства для квотирования: quota и refquota. Свойство quota устанавливает максимальный размер, который могут использовать набор данных и все его потомки. Свойство refquota устанавливает максимальный объем пространства, который может использовать набор данных, исключая его потомков. Если вам нужны квоты, которые исключают снимки и дочерние наборы данных, применяйте свойство refquota.

Почему вы можете хотеть применять refquota вместо quota? Предположим, каждый домашний каталог пользователя является его собственным набором данных, и пользователи не могут создавать снимки. Большинство не может, а большая часть из тех, кто может - не знают как. Если вы автоматически создаете снимки, как мы покажем это в Главе 7, то пространство, используемое такими снимками будет относиться на счет пользователя. Выходящий за пределы использования пространства может удалять некоторые файлы, однако обнаруживает, что он не освобождает все пространство. По- видимому, будет несправедливо взимать плату с пользователя за пространство, которым он не управляет. (Системные администраторы, которые рассчитывают "быть справедливым для пользователей" за пределами их обычной компетенции, могут применять refquota как способ снижения воздействия на пользовательских блох.)

Для настройки квоты на наборе данных назначьте свойство quota и/ или refquota.

В разделе Резервирования мы выделили 20ГБ для системных журналов в наборе данных zroot/var/log, гарантируя, что журнал всегда будет иметь по крайней мере 20ГБ пространства. Более общая задача заключается в случае, когда журнал выходит из под контроля и поглощает все доступное дисковое пространство, обрушивая систему. Ваша система наблюдения должна отловить эту ошибку, но также не лишено смысла установить квотирование для набора данных журналов с тем, чтобы кто-то, убрав комментарий с /var/log/all.log в /etc/syslog.conf не привел компьютер к краху днем позже.

Здесь мы установим квоту на zroot/var/log.

# zfs set quota=100G zroot/var/log
	   

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

При помощи refquota вы можете ограничить объем ссылочных данных. Это исключит дочерние наборы данных и снимки. Ограничение как размера всего набора данных, так и ссылочных данных этого набора данных может помочь вам управлять размером ваших снимков. Например, установка refquota в 10ГБ, а quota в 100ГБ подскажет вам, что вы всегда можете иметь 10 снимков, даже если данные изменяются полностью. Аналогично, если вы хотите исключить дочерние наборы данных, применяйте refquota.

# zfs set refquota=50G zroot/var/log
# zfs set refquota=50G zroot/var/log/db
# zfs set quota=500G zroot/var/log
	   

Здесь у нас есть отдельные refquota для двух наборов данных журналов, а также квота на оба набора данных вместе. Если каждый набор данных может ссылаться на объем до 50ГБ внутри себя, то квота 500ГБ означает, что вне зависимости от того, как изменялись данные, вы можете иметь по крайней мере по четыре снимка каждого из них.

Для просмотра квотирований набора данных проверьте его свойства quota и refquota.

# zfs get all zroot/home | grep quota
zroot/home  quota     none  default
zroot/home  refquota  none  default
	   

Каталог /home не имеет своих квот. Пользователи могут заполнить ваш диск до его пределов.

Квоты изменяют максимальный размер набора данных и свободное пространство в этом наборе данных. Данный пул имеет несколько сот свободных гигабайт, однако zfs list на данном наборе данных сообщит другое.

# zfs list zroot/var/log
NAME           USED   AVAIL  REFER  MOUNTPOINT
zroot/var/log  25.0G  75.0G  5.01G  /var/log
	   

Набор данных zroot/var/log содержит 25ГБ и 75ГБ в нем свободны. ZFS знает, что данный набор данных имеет квоту в 100ГБ и она отображает использование соответствующим образом. При помощи квот вы просто имитируете обычные разделы - однако не выполняйте df(1)! Для начала взглянем на дочерний набор данных zroot/var/log.

# zfs list zroot/var/log/db
NAME              USED   AVAIL  REFER  MOUNTPOINT
zroot/var/log/db  20.0G  85.0G  10.0G  /var/log/db
	   

ZFS знает, что родительский набор данных имеет квоту в 100ГБ, и, тем самым, устанавливает максимальный размер на данный потомственный набор данных. Если /var/log имеет свободными 75ГБ, а /var/log/db имеет свободными 85ГБ, означает ли это, что два раздела имеют (75 + 85=) 160ГБ свободного пространства? Нет, потому что как и свободное пространство пула, эти два элемента ссылаются на одно и тоже свободное пространство. То, что, как представляется, набор данных zroot/var/log должен иметь больше свободного пространства в своем родительском наборе данных, не отражается на использовании пространства дочерними наборами данных.

Если пользователь или процесс попытаются записать нечто,что будет превосходить свои квоты, они получат ошибку квотирования.

# cp script.sh testscript.sh
cp: testscript.sh: Disc quota exceeded
	   

Вам придется освободить свободное пространство, однако, запомните, что снимки осложняют это, как это уже обсуждалось в "Освобождении пространства" ранее в этой главе. Если вы установите и quota, и refquota, пользователь будет способен удалять файлы и освобождать пространство, даже не смотря на то, что это увеличивает размеры снимков файловой системы.

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

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

Команда zfs userspace позволяет вам увидеть сколько пространства используется каждым пользователем в наборе данных. Здесь мы опрашиваем набор данных zroot/home в нашей тестовой системе. Система со сложными наборами данных может потребовать нескольких минут для du(1), однако zfs userspace позволяет найти все файлы всех владельцев почти мгновенно.

# zfs userspace zroot/home
TYPE        NAME      USED  QUOTA
POSIX User  179      7.29M   none
POSIX User  mwlucas  1.16G   none
POSIX User  root      298M   none
	   

Пользователь mwlucas имеет 1.16ГБ файлов - не удивительно. Пользователь root имеет 298МБ файлов в /home - что-то удивительное, но не шокирующее. Так или иначе, пользователь 179 имеет 7.29МБ файлов в этом наборе данных. Данная система не имеет никакого пользователя 179, что объясняется тем, что отображается UID пользователя, а не его имя. Небольшое углубление показывает, что Лукас как-то использовал аргумент -p tar при выделении исходного кода tarball, сохраняя первоначального владельца файла.

Ни один из этих пользователей не имеет квот.

Команда zfs groupspace показывает какой объем файлового пространства используется владельцами каждой группы. Для получения чего-то еще более интересного, я проверяю владения группами в нашем наборе данных zroot/usr/local.

# zfs groupspace zroot/usr/local
TYPE         NAME         USED  QUOTA
POSIX Group  _tss        25.5K   none
POSIX Group  bin         93.5K   none
POSIX Group  kmem         128K   none
POSIX Group  messagebus   392K   none
POSIX Group  polkit       115K   none
POSIX Group  wheel       1.85G   none
	   

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

Для назначения квот пользователям и группам применяйте свойства userquota и groupquota. Для определения того, к какой квоте относится те или иные пользователи или группы, задавайте имя свойства, знак @ и имя пользователя или группы. Например, зададим квоту пользователю mwlucas при помощи userquota@mwlucas.

# zfs set userquota@mwlucas=1G zroot/home
	   

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

$ touch test
touch: test: Disc quota exceeded
	   

Аналогично, назначайте квоту группы с применением свойства groupquota, знака @ и имени группы.

# zfs set groupquota@staff=10G zroot/home
	   

Если пользователь неоднократно жестко обращается с совместно используемыми каталогами подобными /tmp, назначьте ему ограничительную квоту.

# zfs set userquota@mwlucas=10m zroot/tmp
	   

Этот пользователь может использовать функциональность наподобие переадресации агента SSH, однако он не сможет раскрывать огромные tarball и монополизировать наше совместно используемое временное пространство.

Чтобы удалить квоту, установите ее значение в none.

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

# zfs get userquota@mwlucas zroot/tmp
NAME       PROPERTY           VALUE  SOURCE
zroot/tmp  userquota@mwlucas  10M    local
	   

Теперь вы можете позволить вашим командам ссориться между собой по поводу занимаемого ими дискового пространства без затрат вашего драгоценного времени. Наши поздравления!

Сжатие ZFS выполняется в пределах набора данных. Вы можете включить сжатие для некоторых наборов данных и не включать для других.

Включение и отключение сжатия выполняется при помощи свойства compression. Здесь мы проверяем установки сжатия.

# zfs get compress zroot/usr
NAME       PROPERTY     VALUE  SOURCE
zroot/usr  compression  off    default
	   

Разрешите сжатие, установив свойство compression. Алгоритм сжатия по умолчанию, LZJB, не является самым эффективным алгоритмом, который предлагает ZFS. Почти во всех случаях используйте сжатие LZ4. Ниже мы разрешаем сжатие на все наборы данных в пуле zroot, а для набора данных zroot/var/cdr назначаем gzip-9.

# zfs set compress=lz4 zroot
# zfs set compress=gzip-9 zroot/var/cdr
	   

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

ZFS поддерживает различные алгоритмы сжатия. Задаваемый по умолчанию, LZJB, был специально разработан для использования файловой системы. Он может быстро сжимать и распаковывать блоки при скромном коэффициенте сжатия. Однако это не самый лучший алгоритм сжатия для повседневного использования.

Алгоритм LZ4 является более новым и более быстрым алгоритмом сжатия, приспособленным для файловых систем. Он превосходит LZJB во всех отношениях. Не все данные сжимаемы, однако LZ4 быстро обнаруживает несжимаемые файлы и не пытаться сжимать их. При включении сжатия для набора данных, используйте LZ4 если только у вас нет специального случая применения для сжатия gzip.

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

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

Gzip имеет девять уровней сжатия, от 1 (самого быстрого, но менее эффективного), до 9 (самого медленного, но самого энергичного). Определяйте уровень сжатия посредством дефиса и номера уровня.

# zfs set compress=gzip-1 zroot/var/log
	   

Если вы определите gzip без уровня, ZFS по умолчанию будет применять уровень 6.

Некоторые свойства дают возможность понять насколько хорошо ZFS сжимает данные.

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

Наборы данных имеют два свойства просто для сценариев сжатия, а именно logicalreferenced и logicalused. Пространство referenced набора данных включает в себя эффект сжатия, однако свойство logicalreferenced исключает сжатие.

Аналогично, свойство used показывает объем пространства, потребляемого на самом деле набором данных и всеми его потомками, в то время как logicalused показывает объем несжатых данных в наборе данных.

Когда вы изучите все это совместно, вы cvj;tnt получить

Как вы можете определить могут ли ваши данные извлечь выгоду от сжатия, или как разные алгоритмы влияют на размер файла? Возьмите некоторые из ваших типичных файлов данных и проверьте их. Воспользуйтесь du(1) или ls -ls чтобы увидеть фактический размер файла на диске. При тестировании своих данных вы захотите использовать целую кучу различных файлов ваших реальных данных. Для данного примера Лукас использовал проект генома человека, скачаный из проекта Gutenberg.

# du hgp.txt
280721   hgp.txt
	   

В несжатом виде этот файл занимает 280,721 блоков, или, приблизительно 274МБ.

Наш набор данных для тестирования называется db. В этом наборе данных у нас больше нет никаких других данных, следовательно, мы можем точно оценить влияние сжатия на этот определенный файл. Теперь, когда мы знаем размер данного файла в несжатом виде, разрешим сжатие и увидим что произойдет.

# zfs set compression=on db
	   

Это активирует сжатие LZJB. Проверим размер файла теперь.

# du hgp.txt
280721 hgp.txt
	   

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

# rm /db/*
# cp /home/mwl/hgp.txt /db
	   

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

# du /db/hgp.txt
139577  /db/hgp.txt
	   

Файл использует только 139,577 блоков, или примерно 136МБ. Он ужался примерно наполовину, как показывают свойства.

# zfs get compressratio,refcompressratio db
NAME  PROPERTY          VALUE  SOURCE
db    compressratio     2.01x  -
db    refcompressratio  2.01x  -
	   

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

Таким образом, алгоритм по умолчанию уменьшил размер наполовину. Давайте попробуем более эффективный LZ4

# zfs set compression=lz4 db
	   

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

# du /db/hgp.txt
146076  /db/hgp.txt
	   

LZ4 сжимает эти данные до 142МБ. LZ4 не настолько эффективен как LZJB на этом определенном файле. Это не сильно шокирует - разные алгоритмы по разному работают на разных данных.

Сможет ли gzip еще улучшить положение вещей?

# zfs set compress=gzip-1 db/text
	   

Повторно скопируем тестовый файл и проверим использование диска.

# du /db/hgp.txt
74104  /db/hgp.txt
	   

Эти данные теперь используют 74МБ, а compressratio набора данных теперь составляет 3.78. Совершенно ясно, что gzip лучше соответствует для этих конкретных данных. Сжатие почти учетверяет нашу эффективность дискового пространства. Хотя это довольно впечатляюще, давайте увеличим объем.

# zfs set compress=gzip-9 db/text
# cp /home/mwl/hgp.txt /db/
# du /db/hgp.txt
63614  /db/hgp.txt
	   

Врубив сжатие на gzip-9 мы уменьшили этот файл в 274МБ до 62МБ, с compressratio 4.41. Gzip-9 позволяет сохранять данных более чем вчетверо больше.

Однако этот пример жульничает. Реально- реально обманывает! Как и надувательство с "записью формул на ладони перед экзаменом по физике"

После удаления стандартных вставок, добавленных проектом Gutenberg, проект генома человека полностью состоит из четырех букв. Это, пожалуй, самый избыточные, наиболее сжимаемые данные реального мира из существующих. Вы не можете ожидать подобного от большинства данных реального мира. (Да, господин Педант, ваши данные реального мира состоят только из нулей и единиц. Сожмите ваши данные до одного 0 и одной 1 и затем посмотрите, как хорошо это работает для вас.)

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

Не так давно Лукас работал для телефонной компании. Телефонная компания хранила более десяти лет записей детализации вызовов (CDR, call detail records) в простом текстовом виде. Эти записи были постоянно доступны для отчетов в середине ночи. Иногда для исследования мошенничества необходимо получать доступ к этим отчеты с помощью инструментов, подобных grep(1) awk(1). Для подобного варианта применения имело смысл разрешение сжатия gzip-9. При измерении при помощи с du(1), ZFS сжимает файлы примерно до 8:1. Однако, если бы нам нужно было постоянно взаимодействовать с этими файлами, LZ4 и несколько сотен долларов дополнительно на жесткие диски имели бы больше смысла.

Взглянем на эти свойства для примеров данных.

# zfs get all db | grep reference
db/text  referenced         48.7M  -
db/text  logicalreferenced  220M   -
	   

Эти наборы данных используют 48.7МБ дискового пространства. Когда вы пренебрегаете сжатием, этот набор данных имеет 220МБ данных. Сжимаемые наборы данных могут хранить больше "логических данных", чем их размер. Это то место, где на самом деле вступает в игру эффективность сжатия. Самая медленная часть чтения и записи данных заключается в их сохранении на носителях. Физический носитель является самой медленной частью дисковой транзакции. Запись 48.7МБ на диск занимает около 22% от длительности записи 220МБ. Разрешая сжатие, вы можете сократить ваше время сохранения на 78% за счет небольших затрат процессорного времени. Если ваш диск может записывать 100 МБ/с, тогда запись 48.7МБ сжатых данных займет около половины секунды. Если вы посмотрите на это с точки зрения приложения, которое записывает эти данные, вы в действительности записали 220 Мб за половину секунды, что эффективно 440МБ/с. Держим пари, что вы не думаете, что диск вашего ноутбук может так управляться!

Если вы сохраняете много небольших файлов, сжатие будет менее эффективным. Файлы меньшие чем размер сектора, все равно будут занимать целый блок данных. Если вы хотите очень-очень настоящее сжатие, применяйте диски с настоящими 512- байтовыми секторами и просите ZFS использовать этот размер сектора. {Прим. пер.: однако имейте ввиду, что, скорее всего, такие диски будут очень - очень старыми и помимо вопросов об их надежности их скорости тоже будут существенно ниже доступных сегодня: в действительности практически все современные диски физически применяют сектора 4K. Подробнее о 4K и 512e дисках в разделе Хранилище на "сырых" дисках Главы 2.}

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

Большинство процессоров, в основном, простаивает. заставьте ленивых тварей хрустеть некоторыми данными!

Чтобы отключить сжатие, установите свойство набора данных compression в значение off

.

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

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

В первом грубом приближения можно считать, что 1ТБ дедуплицированных данных использует около 5ГБ оперативной памяти. Вы можете более точно апроксимировать потребность памяти для ваших конкретных данных, просмотрев ваш пул данных и выполнив некоторые вычисления. Мы рекомендуем всегда выполнять математические вычисления и определять сколько оперативной памяти нужно вашим данным, а затем использовать наиболее пессимистичный результат. Если математика дает вам число больше 5ГБ, используйте результат вычислений. Если нет, предполагайте 5ГБ на терабайт.

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

Каждый блок файловой системы в наборе данных с дедупликацией использует около 320 байт оперативной памяти. Инструмент ZFS zdb(8) может проанализировать пул, чтобы определить сколько блоков будет использоваться. Используйте флаг -b и имя пула, который вы хотите проанализировать.

# zdb -b data
Traversing all blocks to verify nothing leaked ...

loading space map for vdev 1 of 2, metaslab 33 of 174 ...
5.45G completed ( 341MB/s) estimated time remaining: 0hr 00min 30sec
	   

Счетчик оставшегося времени ("time remaining") не слишком ужасен, что хорошо, поскольку процесс может выполняться очень долгое время в зависимости от скорости диска и использования. После его выполнения вы получите статистический анализ вашего пула.

bp count: 139025
ganged count: 0
bp logical:    18083569152  avg: 130074
bp physical:   18070658560  avg: 129981 compression: 1.00
bp allocated:  18076997120  avg: 130026 compression: 1.00
bp deduped:         0     ref>1: 0 deduplication: 1.00
SPA allocated: 18076997120 used: 1.81%

additional, non-pointer bps of type 0:    21
Dittoed blocks on same vdev: 1183
	   

Счетчик bp ("bp count") показывает общее число блоков ZFS, хранящихся в вашем пуле. Данный пул использует 139 025 блоков. Хотя ZFS по умолчанию использует максимальный размер блока 128кБ, небольшие файлы используют меньшие блоки. Если в пуле есть больше небольших файлов, вам нужно больше памяти.

В третьей строке снизу элемент "используется" ("used") отображает, что данный пул используется на 1.81% (0.0181). Предположим, что данные в этом пуле останутся достаточно последовательными пр мере его роста. Округлим число используемых блоков до 140 000. Разделим используемые блоки на заполнение блоками и мы увидим, что полный пул будет иметь примерно (140 000/0.0181 =) 7 734 806 блоков. При 320 байтах на блок эти данные используют 2 475 138 121байт, или примерно 2.3ГБ.

Это меньше чем половина правила. Предположим, что таблице дедупликации понадобится 5ГБ на терабайт хранимых данных.

ZFS позволит метаданным, подобным таблице дедупликации занять только 25% памяти системы. (В действительности, это 25% от кэша адаптивного замещения- ARC, Adaptive Replacement Cache, но мы обсудим эти детали в книге FreeBSD Mastery: Advanced ZFS.) Каждый терабайт пула с дедупликацией означает, что системе потрубуется как минимум 20ГБ оперативной памяти. Даже если вы будете следовать более обнадеживающей математике использования блока, при которой каждый терабайт диска требует 2.3ГБ оперативной памяти, предел в 25% означает, что каждый терабайт пула с дедупликацией требует примерно 10ГБ оперативной памяти. (В FreeBSD Mastery: Advanced ZFS мы обсудим выравнивание этого предела, чтобы люди, которые хотят выстрелить себе в ногу, могли сделать это хорошо.)

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

# zdb -S data
Simulated DDT histogram:
...
dedup = 3.68, compress = 1.00, copies = 1.00, dedup * compress / copies = 3.68
	   

Наш пул данных может быть дедуплицирован в 3.68 раза. Если все данные в этом пуле были бы дедуплицируемыми, мы могли бы заполнять 3.68ТБ данных каждый терабайт хранилища. Такие данные, однако, исключительно избыточны. Для сравнения, на рабочем месте Лукаса пул zroot, который содержит операционную систему FreeBSD, пользовательские программы и домашние каталоги, имеет дедупликацию приблизительно 1.06.

Это не плохо. Нам все еще нужна машина с 20ГБ оперативной памяти на терабайт пула с дедупликацией, не забудьте, однако теперь мы можем вычислить стоимость/ преимущества на основе текущих потребностей в аппаратных средствах. Вы также можете сравнить свои тестовые данные дедуплицируемости со сжимаемостью.

Являются ли расходы на память стоящими? Это зависит от стоимости памяти в сравнении со стоимостью хранения.

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

Возможно, дедупликация имеет смысл только при ограниченном, дорогом и очень высоко производительном дисковом пространстве. Если вам нужно втиснуть много дедуплицируемых данных в пул SSD, дедупликация может быть вашим выбором.

Однако, все данные различны, поэтому проверьте свои перед принятием решения.

Свойство ZFS dedup активирует и отключает дедупликацию.

# zfs set dedup=on data/data1
	   

Теперь дедупликация активна в этом наборе данных.

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

Чтобы отключить дедупликацию, установите свойство dedup вашего набора данных в значение off

# zfs set dedup=off data/data1
	   

Как и в случае со сжатием, запрет на дедупликацию не реплицирует магическим образом все ваши файлы. Дедуплицированные файлы останутся таковыми. Если вы выключаете dedup по той причине, что она делает производительность системы отвратительной, простое ее выключение не улучшит производительность. Улучшит производительность {после выключения дедупликации} только удаление дедуплицированных файлов. Вы не можете вычистить все следы dedup из набора данных. Вам лучше воспользоваться zfs send и zfs receive для пересылки данных в новый набор данных, который не применяет дедупликацию.

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

Выбор правильной стратегии управления дисковым пространством в начале сэкономит вам много таблеток от головной боли в последующем.