не, прошёл бы.

Расскажи это админу развалившегося пула в нагруженном проде, где за нарушение SLA могут лишить премии или чего-нибудь похуже ...

Ну значит такое решение выбрал, что уж там. Сам виноват.

У меня в проде кстати v0.6.x работал с ресилверингом понадежнее, чем v0.7.12 Один раз даже пришлось менять диск на ходу еще 22 июня 2015 года.

Ctrl+C на источнике "zfs send ..." - это наобум? Репликация выглядит примерно так: zfs send -I DS@S1 DS@S2 | pv | ssh host "zfs receive XXX" Прерываю репликацию на источнике, на приемнике по прежнему висит сессия с receive, особенно если после потери связи (выключение интерфейса по таймеру например или выдергивание кабеля) или даже предположительно Ctrl+C на источнике. Прибиваю на приемнике shell сессию с receive по kill -s 9, она вроде бы даже и невсегда прибивается. Далее пытаюсь сделать ssh host "zfs rollback XXX@S1", вроде бы даже проходит. Дальнейшие попытки репликации сообщают, что XXX занят. Даже zpool export XXX_pool говорит, что пул занят, пишите в спортлото. Как на хосте приемнике - host датасет XXX вернуть в исходное состояние, готовое к репликации с источником ? ессно БЕЗ ребута.

If the sending process was interrupted and we ask ZFS to not clean up the data, we can’t send other data to the same dataset. Instead, we have to continue in the place interrupt occurred, or we have to abort it. Another option is to force send using ‘-F’ options which rollback all the changes, which basically means we will rollback all the send.

Ctrl+C на источнике "zfs send ..." - это наобум? Репликация выглядит примерно так: zfs send -I DS@S1 DS@S2 | pv | ssh host "zfs receive XXX" Прерываю репликацию на источнике, на приемнике по прежнему висит сессия с receive, особенно если после потери связи (выключение интерфейса по таймеру например или выдергивание кабеля) или даже предположительно Ctrl+C на источнике. Прибиваю на приемнике shell сессию с receive по kill -s 9, она вроде бы даже и невсегда прибивается. Далее пытаюсь сделать ssh host "zfs rollback XXX@S1", вроде бы даже проходит. Дальнейшие попытки репликации сообщают, что XXX занят. Даже zpool export XXX_pool говорит, что пул занят, пишите в спортлото. Как на хосте приемнике - host датасет XXX вернуть в исходное состояние, готовое к репликации с источником ? ессно БЕЗ ребута.

можно будет дальше поискать чего как это всё привести в нормальное состояние

была бага в 0.7 с бесконечным ресильвером. в самом последнем релизе (вроде 0.7.13) решили проблему

там zed косячил, решалось его отключением на ресильвер

если сможешь воспроизвести ситуацию - будет прекрасно.

Демонстрация рулезности ZFS на примере вычитывания данных с медленно умирающих дисков: https://ashish.blog/2020/04/resume-support-in-zfs-send/receive/ Как раз с опцией продолжения receive -s

оно умеет определять и перепрыгивать побитые блоки, как ddrescue ?

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

Воспроизвести я могу еще более интересную ситуацию, когда после копирования через dd образа пула на исправное устройство этот пул будет сыпать CRC ошибками и потом вероятно помрет через несколько дней скраба. Разработчики мне написали, что такого не может быть, потому что не может быть :) и закрыли issue :(

Воспроизвести я могу еще более интересную ситуацию, когда после копирования через dd образа пула на исправное устройство этот пул будет сыпать CRC ошибками и потом вероятно помрет через несколько дней скраба. Разработчики мне написали, что такого не может быть, потому что не может быть :) и закрыли issue :( на issue

Issue под анонимной учеткой, не хочу ее палить. Можешь поиском по ключу ganstalking.

но первый скраб это должен выявить

Скраб только увеличивает количество ошибок и вообще любые чтения аналогично. Ошибки вероятно в метаданных или вообще какие-то мнимые ошибки - может быть бага. Копия пула у меня сохранилась, причем проблема не в пуле, а именно в содержимом dd образа vdev, при его выталкивании из пула проблема исчезает. Но как я уже упоминал, этот образ этого проблемного vdev будет сыпать CRC и потом вообще помрет на любом вашем самом дорогом и надежном оборудовании.

надо было сверить содержимое дисков после dd перед импортом первым

Ну вот если этот образ скопирует кто угодно из этого чата на свои распрекрасные сверхнадежные устройства, то все повторится. Значит у всех участников этого чата неисправное оборудование?

повторюсь - надо сначала сверить соответствие образа оригиналу

Так на оригинале были атаки по цепи питания во время появления этих ошибок. После перезагрузки пул импортировался вообще кое как принудительно.

ну если оригинал битый то какие вопросы то

если оригинал работает, а копии сыпятся - в процессе копирования что-то пошло не так

Так на оригинале были атаки по цепи питания во время появления этих ошибок. После перезагрузки пул импортировался вообще кое как принудительно.

круто что данные то позволил zfs достать ещё при таких проблемах с оборудованием)

Всем здравствуйте, помогите рещить проблему. Есть Proxmox 6.4 на нем пул raidz1 в котором 5 одинаковых ssd Samsung_SSD_870_QVO_2TB висят на контролере LSI 9300-8I SGL 12Gb/s HBA. Периодически на дисках (то на одном то надругом) по команде zpool status вижу ошибки: NAME STATE READ WRITE CKSUM DATA DEGRADED 0 0 0 raidz1-0 DEGRADED 0 0 0 ata-Samsung_SSD_870_QVO_2TB_S5SUNF0NC09296E ONLINE 0 0 0 ata-Samsung_SSD_870_QVO_2TB_S5SUNF0NC09271X ONLINE 0 0 0 spare-2 DEGRADED 0 0 0 ata-Samsung_SSD_870_QVO_2TB_S5SUNF0NC09297X FAULTED 9 20 0 too many errors ata-Samsung_SSD_870_QVO_2TB_S5SUNF0NC09266F ONLINE 0 0 0 ata-Samsung_SSD_870_QVO_2TB_S5SUNF0NC09294J ONLINE 0 0 0 spares ata-Samsung_SSD_870_QVO_2TB_S5SUNF0NC09266F INUSE currently in use errors: No known data errors smart гворит что диск в полном порядке. Всю голову сломал, уже не знаю куда копать

Обновите прошивку на контроллере до последней, ловил такие ошибки

Всем привет. Беда такая, есть пул zst на нем лежит реально 340 гиг, но он говорит что занято 100% места. Удаление данных тоже не освобождает место... Подскажет кто как дебажить?

наверно thin надо включить

Подскажите как это делается?

А почему так выходит что пул занят в 100% но самих данных там и на половину нет?

проверь на датасеты zfs get reservation

это не raidz?

А почему так выходит что пул занят в 100% но самих данных там и на половину нет?

Вероятно забит снэпшотами? В таком случае удаление данных по rm только увеличивает потребление пространства, а уменьшает его: zfs destroy xxx/yyy@zzz

если ashift большой

Не

если ashift большой

zfs list -t snapshot -r pool_name не покажет большого количества снэпшотов?

12

Ну если recordsize небольшой, то метадата может немало сожрать при ashift12 - ее размер от блока zfs зависит

Удаляля виртуалки целые, место не освобождается

Может быть, виртуалки "удаляются" только в GUI, а датасеты остаются? Какая-нибудь бага конфига и т.п.?

Удаляля виртуалки целые, место не освобождается

Есть одна виртуалко где много мелких записей, если е1 дропнуть попустить может?