> В случае починки основательно разваленной ФС волновать будет не скорость. Программно -
> всяко быстрее чем ручками файлы доставать, вручную парся структуры с калькулятором
> и хексредактором, потому что сама ФС видите ли облажалась и выпала
> в немоунтабельное состояние или состояние при котором драйвер с грохотом валится.Свежий случай на системном пуле, заполненном на 99% от полезной ёмкости:
не найден загрузочный пул ("can't find boot pool", и при попытке загрузки вываливается приглашение загрузчика). Сам пул импортируется/экспортируется обычным образом в ОС с диска восстановления, файлы целы, scrub после многочасовой проверки показывает отсутствие ошибок.
>> Чтобы больше не попадать впросак с заявлениями о невозможности восстановления ZFS или
>> необходимости в ручном редактировании структур файловой системы,
> Гораздо интереснее было бы посмотреть на твою мину при восстановлении всерьез рассыпавшегося
> пула, когда драйвер не сможет это подхватить, а полноценных утилей восстановления
> как бы и нету толком.
Ты всерьёз полагаешь, что я огорчусь от рассыпавшегося пула? Я тебя огорчу: у меня есть бэкапы и резервирование важных данных.
>> И, да, у ZFSных камикадзей есть man zpool:
>> В котором описана волшебная команда zpool scrub pool...
> А толку? Это не есть полный аналог fsck.
А толку от fsck?!
У нас хотя бы есть scrub, который чинит, если есть возможность, саму ФС и файлы на ней, и показывает в выхлопе список всех повреждённых, невозможных к починке файлов с полными путями к ним. А ваш fsck складывает найденные цепочки блоков в безымянные файлы в каталог lost+found — разбирайтесь сами, что там такое и нужно ли вам оно. :))
