Я использую снимки LVM для резервного копирования баз данных MySQL.
FLUSH TABLES WITH READ LOCKвыдается и затем lvcreate --snapshot --size 4Gи т. д. Поскольку база данных активна, пока снимок активен, snap_percent(объем хранилища снимков, используемый для отслеживания дельт с исходным состоянием файловой системы на момент создания снимка) начинает увеличиваться. Это snap_percentотслеживается изо дня в день и --sizeувеличивается в случае, если достигает 80%.
Мой вопрос заключается в том, существует ли эквивалентная статистика или свойство вЗФСдля определения того, сколько места потребляет снимок в процентах от оставшегося места в пуле? Очевидно, мне не нужно передавать параметр, --sizeно zfs snapshotкак я могу определить, приближается ли клон, основанный на этом снимке, к пределам пула.
Надеюсь, это понятно. Сейчас, когда я это прочитал, вопрос, конечно, звучит запутанно.
решение1
Пространство моментального снимка ZFS отражается в потреблении файловой системы. Вы можете получить то, что запрашиваете, отслеживая наиболее подходящие поля ниже.
В конце концов, вы увидите доступное пространство вашей файловой системы... Видите, как "used"+"avail" меньше, чем "size"?:
root@deore:~# df -h /volumes/vol1/LA_Specialty
Filesystem size used avail capacity Mounted on
vol1/LA_Specialty 800G 391G 254G 61% /volumes/vol1/LA_Specialty
Я отфильтровал вывод zfs get all pool/filesystemниже, чтобы показать соответствующие свойства. Ниже у меня есть файловая система размером 800 ГБ (квота), где используется 545 ГБ. 391 ГБ — этоссылается, то есть это размер реальных данных. 154 ГБ используются моментальными снимками.
root@deore:/volumes# zfs get all vol1/LA_Specialty
NAME PROPERTY VALUE SOURCE
vol1/LA_Specialty type filesystem -
vol1/LA_Specialty creation Sat Sep 24 18:44 2011 -
vol1/LA_Specialty used 545G -
vol1/LA_Specialty available 255G -
vol1/LA_Specialty referenced 391G -
vol1/LA_Specialty compressratio 2.96x -
vol1/LA_Specialty quota 800G local
vol1/LA_Specialty reservation none default
vol1/LA_Specialty recordsize 16K local
vol1/LA_Specialty mountpoint /volumes/vol1/LA_Specialty inherited from vol1
vol1/LA_Specialty usedbysnapshots 154G -
vol1/LA_Specialty usedbydataset 391G -
vol1/LA_Specialty usedbychildren 0 -
vol1/LA_Specialty usedbyrefreservation 0 -
Затем, просматривая снимки... можно увидеть индивидуальный размер снимков и общий размер данных, на которые они ссылаются.
root@deore:/volumes# zfs list -t snapshot
NAME USED AVAIL REFER MOUNTPOINT
vol1/LA_Specialty@snap-daily-1-2013-09-07-020003 57.6G - 389G -
vol1/LA_Specialty@snap-daily-1-2013-09-08-020003 1.95G - 391G -
vol1/LA_Specialty@snap-daily-1-2013-09-09-020008 3.42G - 392G -
vol1/LA_Specialty@snap-daily-1-2013-09-10-020003 3.05G - 391G -
vol1/LA_Specialty@snap-daily-1-2013-09-11-020003 2.81G - 391G -
vol1/LA_Specialty@snap-daily-1-2013-09-12-020004 2.65G - 391G -
vol1/LA_Specialty@snap-daily-1-2013-09-13-020003 2.70G - 391G -
vol1/LA_Specialty@snap-daily-1-2013-09-14-020003 25K - 391G -
vol1/LA_Specialty@snap-daily-1-latest 25K - 391G -
И duсписок каталога снимков...
root@deore:/volumes/vol1/LA_Specialty/.zfs/snapshot# du -skh *
389G snap-daily-1-2013-09-07-020003
391G snap-daily-1-2013-09-08-020003
392G snap-daily-1-2013-09-09-020008
391G snap-daily-1-2013-09-10-020003
391G snap-daily-1-2013-09-11-020003
391G snap-daily-1-2013-09-12-020004
391G snap-daily-1-2013-09-13-020003
391G snap-daily-1-2013-09-14-020003
391G snap-daily-1-latest
решение2
Снимки ZFS содержат много скрытых данных. Обычно я бы рекомендовал вам
zfs list -ro space
Что показывает вывод, аналогичный следующему:
NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD
rootpool/export/home 6.37G 11.7G 2.80G 8.87G 0 0
rootpool/export/[email protected] - 134M - - - -
rootpool/export/[email protected] - 320M - - - -
rootpool/export/[email protected] - 251M - - - -
rootpool/export/[email protected] - 1.02M - - - -
rootpool/export/[email protected] - 1.04M - - - -
rootpool/export/[email protected] - 850K - - - -
rootpool/export/[email protected] - 747K - - - -
rootpool/export/[email protected] - 326K - - - -
rootpool/export/[email protected] - 454K - - - -
rootpool/export/[email protected] - 319K - - - -
Это скажет вам, что я использую ВСЕГО 11,7 ГБ на этом конкретном наборе данных, и что 2,8 ГБ используются моментальными снимками, а 8,87 ГБ используются фактической файловой системой (активными данными). Однако размер ИСПОЛЬЗУЕМОГО рядом с каждым моментальным снимком очень обманчив.
Если вы сложите все числа в столбце used для снимка, вы увидите, что они даже близко не приближаются к итогу USEDSNAP. Это потому, что значение USED — это то, сколькоуникальныйпространство, занимаемое каждым снимком.
Например:
Если у меня есть пул с именем «newpool» и в нем есть 2 файла по 1 ГБ (fileA и fileB):
NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD
newpool 11.0G 2.0G 0.00G 2.0G 0 0
Теперь я это снимаю:
NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD
newpool 11.0G 2.0G 0.00G 2.0G 0 0
newpool@snap1 11.0G 0.0G 0.00G 2.0G 0 0
Теперь я удаляю 1 из файлов размером 1G (файлA):
NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD
newpool 11.0G 2.0G 1.00G 1.0G 0 0
newpool@snap1 - 1.0G - - - -
Теперь я создаю новый файл размером 1G (fileC):
NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD
newpool 10.0G 3.0G 1.00G 2.0G 0 0
newpool@snap1 - 1.0G - - - -
Теперь я снова это делаю.
NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD
newpool 10.0G 3.0G 1.00G 2.0G 0 0
newpool@snap1 - 1.0G - - - -
newpool@snap2 - 0.0G - - - -
Теперь я удаляю файл B (который есть в обоих снимках):
NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD
newpool 10.0G 3.0G 2.00G 1.0G 0 0
newpool@snap1 - 1.0G - - - -
newpool@snap2 - 0.0G - - - -
Обратите внимание, как изменился снимок столбца USED.нетотражают изменение? Это потому, что fileB ссылался на оба снимка, и поскольку он не является уникальным, он не отображается в счетчике USED для какого-либо конкретного снимка. Столбец USEDSNAP отражает, что пространство было использовано снимками, но он не связывает его с каким-либо конкретным снимком.
Теперь, если бы вы удалили snap1:
NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD
newpool 11.0G 2.0G 1.00G 1.0G 0 0
newpool@snap2 - 1.0G - - - -
snap2 теперь показывает, что используется 1,0 ГБ, поскольку эти данные теперь уникальны для этого снимка.
Столбец USED покажет вам, сколько места вы можете освободить, если удалите этот отдельный снимок, но не покажет вам, сколько места на самом деле занимает этот снимок.
Итак, теперь, когда я все это сказал,
Если вы планируете сохранить только один снимок конкретного набора данных, тоzfs список -ro пространствокоманда должна дать вам то, что вы ищете.
Если вы собираетесь иметь несколько снимков одновременно, эти данные могут быть обманчивыми. Не делайте то, что кажется естественным, и не предполагайте, что столбец USED что-то значит, когда имеете дело с несколькими снимками. Также,ду— плохой выбор для каталогов моментальных снимков, поскольку он просто показывает, на что ссылается снимок, а не какое пространство он фактически использует.
Страница руководства zfs частично рассматривает эти вопросы, но она не очень хорошо отображает эти взаимосвязи.
решение3
Прямого эквивалента в ZFS нет. Ближайший эквивалент — свободное пространство в пуле, которое можно получить из zfs list. В ZFS ваши снимки могут расти до тех пор, пока весь пул не заполнится.