Так есть же draid теперь, разве он не убил ещё raid-z* ?

инерция, потихоньку переберутся

#Проблема. Экспортированный пул из множества vdev не импортируется. Пул был импортировал с другим именем и снова экспортирован. Теперь при импорте один из vdev, мистическим образом, виден со старым именем пула, а остальные с новым. Во прос: Что делать? и Кто виноват? https://pastebin.com/G1bZDC16

Архив есть? Самое быстрое решение лежит в наличии архива, полагаю.

Там сложный вопрос, дело не в архиве. Это старый массив, который не планировалось импортировать, но сейчас потребовалось, чтобы разобраться в том какие точки монтирования использовались до экспорта.... в общем, тот случай, когда архив бесполезен ) Но дело не в этом. Я знал что, может быть потребуется взглянуть на эти данные и диски далеко не убирал. Произошедшее для меня полнейшая неожиданность. Как такая ситуация вообще могла возникнуть?

#Проблема. Экспортированный пул из множества vdev не импортируется. Пул был импортировал с другим именем и снова экспортирован. Теперь при импорте один из vdev, мистическим образом, виден со старым именем пула, а остальные с новым. Во прос: Что делать? и Кто виноват? https://pastebin.com/G1bZDC16

# ioping -D /dev/sdb9 4 KiB <<< /dev/sdb9 (block device 8 MiB): request=1 time=696.5 ms (warmup) 4 KiB <<< /dev/sdb9 (block device 8 MiB): request=2 time=66.5 ms 4 KiB <<< /dev/sdb9 (block device 8 MiB): request=3 time=427.2 ms 4 KiB <<< /dev/sdb9 (block device 8 MiB): request=4 time=270.9 ms 4 KiB <<< /dev/sdb9 (block device 8 MiB): request=5 time=3.16 ms 4 KiB <<< /dev/sdb9 (block device 8 MiB): request=6 time=257.3 ms 4 KiB <<< /dev/sdb9 (block device 8 MiB): request=7 time=389.8 ms 4 KiB <<< /dev/sdb9 (block device 8 MiB): request=8 time=567.4 ms (slow) 4 KiB <<< /dev/sdb9 (block device 8 MiB): request=9 time=109.9 ms 4 KiB <<< /dev/sdb9 (block device 8 MiB): request=10 time=780.6 ms (slow) 4 KiB <<< /dev/sdb9 (block device 8 MiB): request=11 time=160.9 ms 4 KiB <<< /dev/sdb9 (block device 8 MiB): request=12 time=500.2 ms 4 KiB <<< /dev/sdb9 (block device 8 MiB): request=13 time=848.0 ms (slow) 4 KiB <<< /dev/sdb9 (block device 8 MiB): request=14 time=107.4 ms норм qlc ссдшка, да

а насколько быстро после экспорта диски обесточили? Не припомню тикетов с такой проблемой, похоже что железо в чём то соврало (либо оч редкий баг, но без репродьюсера дебажить нереально)

Посыпаю голову пеплом! ZFS не виновата. В корзину на самом деле были вставлены левые диски. Меня ввело в заблуждение что у обоих пулов совпадает номер vdev: в одном есть только второй vdev, а в другом есть все, кроме второго. Но при ближайшем рассмотрении, выяснилось, что это вообще были две SSD другого объема и вообще там были метаданные. Недостающие диски нашли, вставили в корзану и все завелось.

Посыпаю голову пеплом! ZFS не виновата. В корзину на самом деле были вставлены левые диски. Меня ввело в заблуждение что у обоих пулов совпадает номер vdev: в одном есть только второй vdev, а в другом есть все, кроме второго. Но при ближайшем рассмотрении, выяснилось, что это вообще были две SSD другого объема и вообще там были метаданные. Недостающие диски нашли, вставили в корзану и все завелось.

Может кто подскажет по следующей ситуации: NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD zroot 6.74G 147G 0B 88K 0B 147G zroot/ROOT 6.74G 41.6G 0B 88K 0B 41.6G zroot/ROOT/default 6.74G 41.6G 0B 41.6G 0B 0B zroot/tmp 6.74G 39.8M 0B 39.8M 0B 0B zroot/usr 6.74G 13.2G 0B 88K 0B 13.2G zroot/usr/home 6.74G 13.2G 0B 13.2G 0B 0B zroot/var 6.74G 92.4G 0B 88K 0B 92.4G zroot/var/audit 6.74G 88K 0B 88K 0B 0B zroot/var/crash 6.74G 88K 0B 88K 0B 0B zroot/var/log 6.74G 92.4G 0B 92.4G 0B 0B zroot/var/mail 6.74G 7.61M 0B 7.61M 0B 0B zroot/var/tmp 6.74G 88K 0B 88K 0B 0B root@serv:log du -d 1 -m /var/log | sort -n 1 /var/log/3proxy 1 /var/log/atop 1 /var/log/cups 1 /var/log/letsencrypt 1 /var/log/netdata 1 /var/log/nut 1 /var/log/samba4 6 /var/log/tor 48 /var/log/smartd 78 /var/log zfs говорит, что /var/log юзает 92 гига, при этом du, считает, что в /var/log лишь 78 метров. Пул - зеркало, снапшотов нет. root@serv:log zfs version zfs-2.0.0-FreeBSD_gf11b09dec zfs-kmod-2.0.0-FreeBSD_gf11b09dec

raidz/снапшоты

ну так поди зфс вместе с метой показывает а ду - по сумме длин файлов

подскажите ктонибудь

блин... ну почему он сьедает ссылку

# zpool import -f pool: OVER id: 7316868942039014810 state: ONLINE status: Some supported features are not enabled on the pool. (Note that they may be intentionally disabled if the 'compatibility' property is set.) action: The pool can be imported using its name or numeric identifier, though some features will not be available without an explicit 'zpool upgrade'. config: OVER ONLINE ata-WDC_WUH721414ALE6L4_QBKVBRUT ONLINE пытаюсь смонтировать - и после выдает ошибку # zpool import -f OVER cannot import 'OVER': I/O error Destroy and re-create the pool from a backup source. если попробовать так - выдает следующее # zpool import -FfmX OVER cannot import 'OVER': one or more devices is currently unavailable удалить его не получается - так понимаю потомучто он не импортирован... # zpool destroy OVER cannot open 'OVER': no such pool

> I/O error с диском точно всё ок?

да в том то и дело - вроде нечего не делал как выше писал - у меня 2 пула было - и сломанный почти не использовался - там просто куча фильмов складировалось и всё в идеале восстановить полностью конечно... там занято 6тб - сейчас проблематично будет их переместить кудато