> директория - это французское правительство времен контр-революции.

Вот оно что! Юниксоиды - буржуазная контра стало быть?!

> А в zfs аналог ваших "subvol" - filesystem.

А ты уверен что 100% аналог? Скажем новый снапшот ZFS - будет технически именно новым filesystem в тех терминах? Или скажем filesystem можно удалить через системные вызовы? Ну там rm обычным и проч? Снапшоты (и сабволы вообще) btrfs/bcachefs можно отменеджить не только родной утилсой - но и просто F8 в миднайте каком. Поскольку это в принципе лишь независимая иерархия, нет особых проблем ее - снести, как диру почти, с довольно небольшими отличиями.

> банально опечатался, получил ошибку, не понял в чем дело и повторил команду.

Ну вот видимо кто-то и заметил что фигня какая-то получается. Фигня досадная но не фатальная.

> Или того проще, ошибка в скрипте вычисляющем имя того что нужно удалить,

Я бы в общем случае побаивался юзать скрипты с ошибкой вычисления сносящие subvol, имхо. Хотя любителям bumblebee понравится. Особенно если у...ть нужный снапшот (для аутентичных ощущений).

> Судя по тому что сразу же и нашли - то либо другое у кого-то и было.

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

> А вот случаи когда люди прямо совсем необратимо теряли пулы zfs -

Так там речь о потере данных вообще не идет. Только о обидном локапе в кишках фс.

> (Да, он в принципе зря стал это делать, но полагаю у
> него просто не было столько лишних денег на второй такой же.)

Ну я вот как-то рестрайпил некий btrfs - и питание улетело. Технически примерно то же самое по смыслу. В общем случае balance являет собой недеструктивную операцию. Конечно любое кантование данных несет некие риски, но т.к. cow сперва создает копию а потом "указатели перевешивает", крах в общем случае не вызывает больших проблем. То что записалось сохраняется, то то не записалось авто-отменяется за отсутствием "указателей" на это. А сам дизайн нормально относится к смеси разных типов block groups, ну ему и пофиг было. Прекрасно маунтится и работает, так что пнуть операцию еще раз - он и доконвертит что еще не успел. Мне вот повезло - flawless conversion, даже после poweloss. Scrub никаких траблов не увидел и все как часики.

Со своей стороны я считаю что управление ФС должно быть - ну вот как-то так, имхо.

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

Если я что-то такое затеваю - тебе не приходило в голову что снапшот по его смыслу это такой мануальный "barrier" на тему состояния ФС в этой точке пространства времени? Я сигналю что считаю это состояние ценным. Это мой key frame в таймлайне. Я требую его не разрушать GC, чтобы иметь возможность на него вернуться.

...а после этого можно хоть "eatmydata apt upgrade" влупить, и если он даже сгорит синим пламенм, мне совершенно не важно что там отъедет, я снапшот "атомарно" в старое состояние верну вместо колупания в деталях факапа. Сэкономив дочерта времени на парировании проблемы. А потом можно попытаться операцию еще раз. "All or nothing" можно заимелементить совместной игрой с машиной, так сильно эффективнее. Ибо я лучше знаю определения "all" и "nothing" в этом контексте.

> Точно-точно ли при этом можно профакать то что не было синкнуто, особенно
> с учетом привычки дисков к write reordering?

Если команды сброса буферов работают как должны, то само по себе это имхо не проблема. А если нет - там с любой ФС при случае гамна можно будет откущать ибо они ВСЕ на эту семантику уповают.

Есть еще всякие совсем левые вещи - типа продолба eraseblock который in-flight при powerloss, но вот тут - сорян, если чушка в 16-64 мега испарилась, любая ФС может дать дуба. У особо неудачливых, с голимым накопителем, глупой фирмварой и неудачным расположением - вместе с партишном заодно. А те кто поумнее догадываются отступить на флешатине от начала девайса достаточно почтенный 2^N (64MiB или более) чтобы партинш в своем eraseblock'е лежал и его не ворочали лишний раз. Т.к. там interleave, это erase group на самом деле, его могут ворочать весь сразу, и он крупнее 1 eraseblock'а, откуда и округление.

В случае "испарения чушки" очень кстати если была избыточность, даже DUP даст нехилые шансы потрепыхаться. По той же причине суперов и у кента и у бтрфс несколько. Что-нибудь да выживает, а дальше self heal по полной версии задумки. На практике - в btrfs рековери суперов таки маниуальная операция. Но вроде недавно таки сделали и опцию автоматически чинить убитый основной супер из запасных.

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

Вообще фирмвари накопителей делают очень много всякой весьма странной фигни, там дочерта quirks, out of spec поведения и левизны. Ну вон у самса например были траблы с trim, вплоть до того что это могло девайс угробить. Не по спекам, но юзеру с дохлым девайсом же не объяснишь, он будет вопить что это ацтой. Имея некий пойнт. Так что там костылей в libata и проч - очень даже. У btrfs'ников кстати описаны "типовые" факапы сторажей в их доках, по их опыту.

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

С практической точки зрения - на серваках - да и моих одноплатниках - этот fsck запускать решительно некому. Так что это как баг - так и фича. Ибо дочерта систем работает, натурально, в режиме автопилота.

И там мы хотим self heal до последнего - пока это можно, с диагностикой и статистикой. А потом - потом система потребует мануальное внимание и это mission failed что так что сяк, детали уже не очень важны. Железки стояли не для того чтобы там fsck запускали. Вообще совсем.