Куда подевалось место на ZFS

Victor Sudakov написал(а) к Vova Uralsky в Nov 17 22:41:20 по местному времени:

Dear Vova,

19 Nov 17 11:29, you wrote to me:

VS>> Справедливости ради должен отметить, что фатального тогда ничего
VS>> не произошло, пул в негодность не пришёл, оно потихоньку
VS>> рассосалось.

VU> Как я уже писал, "Про ZFS рассказывают страшные вещи".

А расскажи вместо страшной полезную вещь, как проверить результат работы "zfs send -R zroot@backup > backup.zfs" без реального разворачивания рекурсивного снапшота backup.zfs, по аналогии с "restore -rN". Места и времени на это обычно нет.

Пробовал с разными ключами "zfs receive -vnFd foo < backup.zfs", и без "-d" тоже: конец один, типа такого:

cannot receive incremental stream: destination 'foo/ROOT/default' does not exist.
или
cannot receive: local origin for clone foo/ROOT/install@2017-11-19 does not exist

Короче, как? Задача - проверить читаемость и целостность дампа. У меня вообще сомнения, что после таких ошибок оно развернется в реальной ситуации.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Andrey Ostanovsky написал(а) к Victor Sudakov в Nov 17 12:11:48 по местному времени:

Нello Victor!

20 Nov 17 22:41, you wrote to Vova Uralsky:

VS> Короче, как? Задача - проверить читаемость и целостность дампа. У меня
VS> вообще сомнения, что после таких ошибок оно развернется в реальной
VS> ситуации.

А что, такая конструкция во фре не работает?

zstreamdump < backup_file


Andrey

--- GoldED+/BSD 1.1.5-b20070503

Victor Sudakov написал(а) к Andrey Ostanovsky в Nov 17 23:00:48 по местному времени:

Dear Andrey,

21 Nov 17 12:11, you wrote to me:

VS>> Короче, как? Задача - проверить читаемость и целостность дампа. У
VS>> меня вообще сомнения, что после таких ошибок оно развернется в
VS>> реальной ситуации.

AO> А что, такая конструкция во фре не работает?

AO> zstreamdump < backup_file

Работает, но код завершения будет 0, даже если в backup_file что-нибудь попортить hex редактором.

Впрочем боюсь что и "zfs receive -n" поведет себя не лучше, я просто ни разу не дождался до конца, оно вылетало не дочитав стрим, по невозможности создать какой-нибудь датасет.


Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Alex Korchmar написал(а) к Victor Sudakov в Nov 17 23:42:56 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Victor Sudakov <Victor.Sudakov@f49.n5005.z2.fidonet.org> wrote:

AO>> zstreamdump < backup_file
VS> Работает, но код завершения будет 0, даже если в backup_file что-нибудь
VS> попортить hex редактором.
если тебя не устраивает проверка только управляющих блоков - то
единственный вариант - таки физически разворачивать на отдельный
носитель, и сравнивать, тупо, cmp. Интересно, какого еще чуда ты ждешь от zfs?


> Alex


--- ifmail v.2.15dev5.4

Victor Sudakov написал(а) к Alex Korchmar в Nov 17 14:31:52 по местному времени:

Dear Alex,

21 Nov 17 23:42, Alex Korchmar wrote to me:

AO>>> zstreamdump < backup_file
VS>> Работает, но код завершения будет 0, даже если в backup_file
VS>> что-нибудь попортить hex редактором.
AK> если тебя не устраивает проверка только управляющих блоков

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

AK> - то
AK> единственный вариант - таки физически разворачивать на отдельный
AK> носитель, и сравнивать, тупо, cmp.

Это одна крайность. А вот другая:

root@vas:~ # echo "Peace to you" > /var/tmp/qqq
root@vas:~ # zstreamdump < /var/tmp/qqq ; echo $?
SUMMARY:
Total DRR_BEGIN records = 0
Total DRR_END records = 0
Total DRR_OBJECT records = 0
Total DRR_FREEOBJECTS records = 0
Total DRR_WRITE records = 0
Total DRRWRITEBYREF records = 0
Total DRRWRITEEMBEDDED records = 0
Total DRR_FREE records = 0
Total DRR_SPILL records = 0
Total records = 0
Total write size = 0 (0x0)
Total stream length = 0 (0x0)
0

Это блин средство проверки бэкапа?

AK> Интересно, какого еще чуда ты ждешь
AK> от zfs?

Разве это чудо, чтобы "zfs receive -n" не вываливалось посреди стрима?

Мне бы что-нибудь уровня "restore -N", которое понимает, что файл преждевременно кончился, или что он внутри попорчен.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Alex Korchmar написал(а) к Victor Sudakov в Nov 17 13:40:53 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Victor Sudakov <Victor.Sudakov@f49.n5005.z2.fidonet.org> wrote:

VS> Это блин средство проверки бэкапа?
это средство проверки читаемости.

AK>> Интересно, какого еще чуда ты ждешь
AK>> от zfs?
VS> Разве это чудо, чтобы "zfs receive -n" не вываливалось посреди стрима?
полагаю, раз тест прошел, этот твой привед zfs receive тоже прожует ;-)
А то, на чем вываливается - вероятнее всего и тест не пройдет.


> Alex

--- ifmail v.2.15dev5.4

Victor Sudakov написал(а) к Alex Korchmar в Nov 17 20:08:32 по местному времени:

Dear Alex,

22 Nov 17 13:40, Alex Korchmar wrote to me:

VS>> Это блин средство проверки бэкапа?
AK> это средство проверки читаемости.

Что за средство проверки читаемости такое, которое не замечает, что конец читаемого бэкапа откусили? В задницу такое средство проверки.

"restore -N" замечает такое на раз (хотя и не очень элегантно реагирует), и checksum incorrect тоже замечает, если в дампе полазить hex-редактором. Подумать только, dump/restore 20+ лет, а контрольные суммы дампа считает.

AK>>> Интересно, какого еще чуда ты ждешь
AK>>> от zfs?
VS>> Разве это чудо, чтобы "zfs receive -n" не вываливалось посреди
VS>> стрима?
AK> полагаю, раз тест прошел, этот твой привед zfs receive тоже прожует
AK> ;-)

Тут есть тонкость. "zfs receive" стрим разворачивает без проблем, а вот "zfs receive -n" обламывается. Вероятнее всего из-за отсутствия промежуточных датасетов, которые в режиме -n разумеется не создаются.

AK> А то, на чем вываливается - вероятнее всего и тест не пройдет.

Проходит. Тест zstreamdump проходит практически любой файл, можешь его напустить на /etc/fstab - тоже пройдет.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Eugene Grosbein написал(а) к All в Feb 18 02:53:25 по местному времени:

27 окт. 2017, пятница, в 19:10 NOVT, Eugene Grosbein написал(а):

EG> Я тут подумал, что может быть наследование даже и необязательно.
EG> Просто на родительском датасете зарезервировать энное количество места
EG> и в случае чего, погасив сервисы, удалить этот резерв и затем
EG> чистить гОвна без проблем.

EG> Собственно, это то же самое, что держать десять мегабайт "порнухи"
EG> на FAT четверть века назад с тем, чтобы можно было её удалить в такой
EG> же момент.

Напоролся в реалии: небольшой пятигигабайтный пул ZFS с несколькими fs
и кучей файлов разного размера, включая содержимое /usr/obj,
на "корневой" файловой системе пула было включено reservation=50M,
но на ней пользовательских данных нет, они на других файловых системах пула,
на которых reservation=none.

ВНЕЗАПНО кончилось место и выглядело это так: df показывал 0 байт свободных
на всех fs пула, пишущие туда процессы типа tar xf стали говорить
Write failed, zpool list показывал занятость пула в 96%.

rm -vrf obj бодренько стал удалять данные, никаких тормозов или локов.

Eugene
--- slrn/1.0.2 (FreeBSD)

Dmitry Ivanov написал(а) к Eugene Grosbein в Feb 18 00:08:10 по местному времени:

Здравствуйте, Eugene.

Вы писали 23 февраля 2018 г., 5:53:25:

> ВНЕЗАПНО кончилось место и выглядело это так: df показывал 0 байт свободных
> на всех fs пула, пишущие туда процессы типа tar xf стали говорить
> Write failed, zpool list показывал занятость пула в 96%.

Во, у меня тоже такое пару раз было. Кажется, только перезагрузкой я
смог это побороть. Есть мысли, как это полечить без рестарта?

--
С уважением,
Dmitry
--- InterSquish NNTP Server/FTN Gate

Eugene Grosbein написал(а) к Dmitry Ivanov в Feb 18 04:55:37 по местному времени:

23 февр. 2018, пятница, в 00:08 NOVT, Dmitry Ivanov написал(а):

>> ВНЕЗАПНО кончилось место и выглядело это так: df показывал 0 байт свободных
>> на всех fs пула, пишущие туда процессы типа tar xf стали говорить
>> Write failed, zpool list показывал занятость пула в 96%.
DI> Во, у меня тоже такое пару раз было. Кажется, только перезагрузкой я
DI> смог это побороть. Есть мысли, как это полечить без рестарта?

Так весь тред был об этом: надо на одном из датасетов пула - например,
на корневой fs - включить reservation на сколько не жалко.

Мне обычно не жалко 100MB, но в данном случае хватило и 50MB.

Eugene
--
Поэты - страшные люди. У них все святое.
--- slrn/1.0.2 (FreeBSD)