> Не нашёл. Прямую ссылку не дашь?

Могу повторить для тех кто на несколько постов промотать вверх не может: http://forum.nginx.org/read.php?21,170638 - там товарисчу рассказали про проблемы с ZFS 8.1 и в этом году. Ах да, для столь невнимательных: форум может портить такие ссылки, почему-то спотыкаясь на запятой. Так что use copy-paste, Luke.

> zfs scrub бессилен что-либо сделать на разрушенном пуле.

Я уже заметил - у чувака оказался разрушенный пул и ... и никаких внятных средств его восстановить простыми методами, хотя-бы в порушенном режиме, мля, когда какие-то данные не прочтутся или в каком-то месте прочтутся криво/не полностью. Для менее подкованного в устройстве ФС фрукта это будет означать что он просрал все полимеры. Идея форсануть откат на предыдущую транзакцию и то что оно даже прокатило и на тот момент ФС была более-менее исправна - азачет за изобретательность. Когда ФС обделалась везде где могла, товарисч ее грамотно обманул, форсанув сбой транзакции :). Но чтобы это сделать - надо весьма прилично разбираться в том как работает ФС и неслабо поупражняться с калькулятором. Я вот что-то не уверен что ты сможешь этот фокус-покус повторить, например ;). Особенное БЕЗ такого мануала.

> Например, ты не сможешь импортировать пул с отсутствующим по каким-либо причинам одним
> из устройств верхнего уровня.

У человека присутствовали все устройства. Облажалась логика рекавери когда транзакция запоролась из-за бэдов как я понимаю. Я конечно понимаю что ситуация не подарок, но как-бы было бы хорошо если бы у ФС были бы средства получше чем "дискэдитор" для выхода из штопора, хотя-бы частичного. А то вручную пинать ФС, засирая трнзакцию чтобы к данным доступиться - "немного" геморройно и пожалуй не всем кулсисопам типа тебя по зубам :))

> Ещё пример: два винчестера объединены в JBOD или stripe, один из
> винчестеров покрылся бэдами == хана пулу. Удивлён? Я — нет.

Ну а я вот недавно отколупал с покрывшегося бэдами винча практически все данные, сперва минимизировав повреждения образа утилитами которые умеют копировать битые диски правильно, а потом отрепайрив снятый образ (ессно копию) fsck'ом. В итоге получил почти все данные с проблемного диска. Кстати чем больше наворочено - тем больше заколебешься вычислять смещения блоков в случае если утилиты все-таки обделаются и придется руками разрюхивать :). Ну или тем дороже заплатишь тем кто это будет рекаверить, если самому слабо а данные нужны.

> И ещё, в ZFSv14 (у автора статьи) отсутствует команда "zpool import -F",
> позволяющая импортировать повреждённый пул с отбросом последних групп транзакций.

Ну, это ж не мешало тебе орать про энтерпрайзность решения :).

> Ну так не боги горшки обжигают. ZFS придумал человек, другой человек тоже
> может понять её структуру.

Да, но как-то хотелось бы средство которое
1) проверит что метаданные корректны
2) если они не корректны, сможет восстановить их настолько насколько это возможно.

Потому что при например вылезании бэдов на диске - могут порушиться данные и/или метаданные в произвольном месте. Стандартная механика СoW имеет право поломаться от такой подляны, т.к. какие-то метаданные могут быть испорчены. Но это не повод просрать целиком и полностью. То что человеку удалось исправить проблему путем форсированного отката транзакции на более старую - ну да, повезло. В том плане что все застряло на сбойных блоках и где-то там и обломалось. Легко догадаться что это лишь частная ситуация :). Мне вот например попался диск где ошибки долго были не обнаруженными, а Генерал Фэйлор посетил обладателя диска при чтении весьма древних данных, которые читаться не захотели, том выпал в R/O а при ребуту отказался монтироваться вообще. Жил он себе, жил, смарт идеальный. А некоторые сектора не прочитались. Хотя совсем нечитабельных оказалось немного но немного данных и метаданных - сыпанулось ессно.

>> ФС с курением сырцов и довольно изобретательным форсированием сбоя прошлой транзакции
> Это свойства CoW не терять ранее записанное, а перезаписывать только самое старое
> логически удалённое.

Да, только вот думаю несложно догадаться что товарисчу повезло что засралась только последняя транзакция и откат этого привел к рабочей ФС. Успешность этого подхода очень зависит от того что и где порушилось. Поэтому утили способные проверить метаданные на корректность в случае когда тома УЖЕ порушены и восстановить насколько возможно - мне лишними не кажутся почему-то.

>> Я бы с удовольствием посмотрел как бы ТЫ таким манером репайрил бы ФС :)
> У меня времени нет на подобные глупости. Это студентам интересно, а мне
> такие вещи уже не бросают вызов,

Скажи уж честнее: твоего мозга и познаний просто не хватит на это. Ну, заплатишь тем у кого хватит, если данные будут нужны, или скрипнешь зубами и просрешь полимеры, известное ж дело :)). Кстати в этом плане CoW механика имеет свои грабли: снапшоты выгдядят как бэкап, НО ОНИ НИ РАЗУ НЕ ЗАМЕНА БЭКАПА! Один порушеный блок в середине цепочки снапшотов - повредит еще все более поздние версии ссылающиеся на него. Например если ты записал файл на чистый винч, а потом отредактировал и СoW дописал довесок в сторонку, а потом вылез бэд под блоками первого состояния файла - ты просираешь и прошлое состояние и текущее. И никакие откаты к снапшоту не помогут. Так что полноценные бэкапы оно не заменяет нихрена.

> чтобы бросаться из-за них на баррикады покорения собственной
> тупости — я стараюсь не допускать до работы глючное железо,
> а уж для критических данных завожу бэкапы.

Ты не поверишь, почти все HDD/SSD вышедшие с фабрики как правило более-менее безглючные - там какие никакие тесты проводят, ибо выбросить глюкало сразу с конвейера намного дешевле чем его потом юзвергу заменять. А потом они могут вдруг начать сбоить. Просто потому что механика - штука нежная, размены измеряются в десятках нанометров. Одна пылинка - и вот уже сектор и то и куча оных и не читается. Флеш может осыпаться, там вообще принцип хранения информации ссыкотный - заряд загоняется в диэлектрик и надеятся что не утечет. На самом деле утекает. Как в SDRAM но намного медленнее, за годы вместо долей секунды. Поэтому кстати на флеше так и упирают на параметр data retention = X years. Все это сильно зависит от техпроцессов, вероятности, удасности-неудачности экземпляра, etc. Уповать на то что проблем никогда не будет - высшая степень наивности. Технологии тонкие, капризные, а для максимального профита - юзаются на грани, без многократного запаса прочности,  и даже хуже: нынче считается что ошибки ECC - это вполне приемлимо и девайс можно выпустить (тут уже начинается полнейшая игра с вероятностью кто кого обыграет). А значит мы будем кушать бэдсектора и дальше. Никуда мы от них не денемся... :)