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

Question

Я использую FreeBSD 11.1, и вывод zfs list -t snap -r poolname показывает большое количество моих снимков с "0" под "USED". Я прочитал о том, как ZFS учитывает пространство, поэтому я понимаю основы, и они предлагают мне, что

1. "0" означает, что моментальный снимок не использует дисковое пространство, в том смысле, что его удаление не восстанавливает дисковое пространство.
2. Если файл присутствует в 2 снимках, это не улучшит избыточность этого файла, потому что все, что он означает, - это наличие нескольких указателей (ссылок) на этот файл (или, точнее, на серию блоков, составляющих этот файл), а не на дополнительные копии существовать.

Таким образом, логика предполагает, что любой снимок с USED = 0, вероятно, будет идентичной копией предыдущего снимка объекта rhat, и его можно безопасно удалить, если вы не хотите сохранять снимки, для которых ничего не изменилось по сравнению с предыдущим снимком, и нет избыточности теряется при этом.

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

• Используемые значения моментальных снимков могут изменяться, когда уничтожаются другие моментальные снимки, но в равной степени наличие нулевого размера должно настоятельно указывать почти при любом обычном использовании, что существует другая моментальная копия ненулевого размера, которой она идентична. Но "настоятельно рекомендует" не означает «неправдоподобно, что это не так», а ноль означает, что все блоки существуют, а не то, что они одинаково организованы, а файлы одинаковы. Существуют ли случаи, когда не всегда безопасно «из-под контроля» удалять все снимки нулевого размера?

• Как пример этого, представьте, что мы (1) создаем файл размером 100 МБ и создаем моментальный снимок пула, затем (2) создаем два других файла размером 75 МБ, содержащих первый и последний 75% файла размером 100 МБ соответственно, и удаляем файл размером 100 МБ, а затем снимок снова. Во втором снимке будет отображаться 0 использованного пространства, поскольку все блоки существуют в предыдущей снимке, но файлы в этом снимке фактически уникальны. Я не могу придумать способ обнаружить это, потому что учет пространства в ZFS основан на блоках, а не на файлах. Возможно, с использованием дедупликации и некоторыми типами файлов, которые добавляются или "хвостятся", это может быть обычным явлением, если редко, а не просто патологическим крайним случаем.

Так что я не уверен. Возможно, размер привязки - это красная сельдь, и мне нужно проверить другие свойства.

Существуют ли нетривиальные обстоятельства, позволяющие безопасно и быстро определить, является ли моментальный снимок ZFS избыточным (в том смысле, в котором я использую этот термин), и безопасно ли его удалять?

Или есть другой лучший (быстрый + эффективный) способ узнать, из других свойств или различий ZFS или чего-либо еще, указывают ли две последовательные привязки на один и тот же момент времени / порядковый номер записи пула в истории пула (что категорически подтвердит, что они ссылаться на идентичные данные)?

Answer 1

USED=0 является разумным показателем того, что снимок является дубликатом предыдущего снимка. Однако вы должны убедиться, что это на самом деле ноль, а не какая-то округленная версия нуля (например, 0,1 КБ, округленная до ближайшего КБ). Вы можете использовать флаг -p («parseable»), чтобы получить точное число, измеренное в байтах. Также обратите внимание, что для обновления учетных номеров пространства может потребоваться несколько секунд после создания снимка.

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

Пример, который вы привели (где блоки распределяются между файлами) может произойти, только если у вас включена дедупликация. В противном случае ZFS все равно будет хранить несколько копий блоков и соответствующим образом учитывать это пространство. Даже с дедупликацией оба вышеописанных метода будут отличаться - снимок не займет нулевое USED пространство, потому что вам понадобятся новые метаданные для двух файлов (два inode плюс косвенные блоки, указывающие на дедуплицированные блоки; возможно, другие вещи, такие как хорошо), и zfs diff покажет +<filename> для двух новых файлов.

РЕДАКТИРОВАТЬ: последний видимый пользователю способ проверить это, запустив zfs send -nv ( пробный запуск, подробный) между снимками. Это не сгенерирует полный поток отправки, но может сказать вам, что будет отправлено, что должно быть ничем, если два снимка совпадают.