ZFS: Как восстановить zpool, если одно из устройств, в него входящее, недоступно?

Пардон, последняя строка должна быть

zpool import tank -f

Т.е. пул не спасти? А данные?

Вы меня поражаете. У вас одна треть из страйпа. Что спасать собрались?

А, теперь понял по комментарию, вы не понимаете что такое пул. Вас спасет документация, она даже на русском есть.

Где вы тут треть страйпа увидели? Если в пуле из 2-3 дисков вылетает диск, то остается либо половина либо 2/3 данных. К тому же, на сколько я понимаю, ZFS пишет на диски последовательно (поэтому есть возможность добавления новых устройств в пул), соответственно после вылета физического диска (vdev) данные не должны превращаться в фарш. Может вам читать документацию, раз ответить нормально не можете?

> Если в пуле из 2-3 дисков вылетает диск, то остается либо половина либо 2/3 данных.

Это было бы справедливо, например, для зеркала из 4 дисков, но не в случае с пулом без избыточности.

> К тому же, на сколько я понимаю, ZFS пишет на диски последовательно

ZFS старается максимально использовать copy-on-write, что конечно в какой-то степени является «последовательной» записью, но не той о которой вы говорите. Данные все равно записываются в блоки. А точнее — в extent'ы (непрерывные последовательности из нескольких блоков), как это сделано и в Ext4, и в XFS. Когда вы делаете пул из нескольких дисков, то выделяемый extent — это абстракция, которая не гарантирует размещения на одном носителе. Поэтому ZFS не подразумевает, что блоки для записи будут выделены только с одного физического диска.

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

И что можно копировать?

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

Хорошо. Допустим я хранил в этом пуле базу данных транзакций по счетам клиентов. Ошибка даже в одном бите данных с упавшего массива (в котором невозможно провести проверку целостности), может стоить вам многих $$$.
Если в массиве хранились картинки и музыка — «рискнуть можно, риска нет». Но в общем случае, я бы не давал такого совета.

В таких случаях нужно подниматься исключительно с бекапа.

> # zpool clear %pool_name%
не дало результата: no such pool
надо сказать, что zpool вообще не видит самого пула. В системе имеется только физический диск с ФС ZFS и меткой по названию пула, однако смонтировать его, разумеется не удается.

>Если в массиве хранились картинки и музыка — «рискнуть можно, риска нет».
Именно. В моем случае для важных данных я использую raid-z, а «картинки и музыку» хочу хранить без избыточности, но и потерять все сразу при крахе лишь одного диска не хочу.

А что в zpool status?

так выше же написал, что пула не видит: no pools available

Я видимо не так истрактовал «не видит пулов». Обычно оно хотя бы DEGRADED…
Хорошо… что даёт команда ниже?
# zpool import -f

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

># zpool import -f
no pools available to import

>Создать на этом девайсе новый пул с тем же именем что и старый, а потом импортировать его.
на этом это на котором? стоит упомянуть, что это пока тестирование и «обвалившийся диск» на самом деле просто отключенный диск (эмулируем вариант полного выхода из строя, что уже не раз я видел в реальности) и никаких важных данных там нет.
В общем попробовал создать новый пул с тем же именем сначала на одном диске, потом на другом — пулы создались, но данных внутри не было. Соотвественно это не выход.