> Ну зашибись, в следующем LTS потестирую.

Это если что в 6.2 или 6.3 кернеле было. Решение компромиссное, изначально была идея заворкэраундить write hole _без_ RMW, но с актуальным дисковым форматом таки оказалось "все сложно".

При том суть проблемы - и что можно делать на этот счет - описано в их вике и readthedocs. При сильном желании можно гонять и без фикса, НО - есть нюансы. А метаданные вообще имеет смысл всегда как RAID1 (data = raid5) или RAID1c3 (data = RAID6) держать, их обычно не очень много и это для метаданных более удачная идея.

> И тем не менее, OpenZFS устроило срач в дмесге, но *ВСЕ* данные
> (все файлы) мне вернуло после такого,

Не спорю что сбитие автомобилем вертолета круто, но практическая польза в чем? Если сторажу совсем плохо, его фирмварь при старте тоже не прочтет служебные регионы, девайс не выйдет на режим. Если кто видел винчи клацающие при старте, девайсы не проходящие идентификацию и проч, знакомьтесь, ОНО. SSD и некоторые иные флешастые еще в readonly уходят когда резерва не осталось. Но это тоже не то. А какой практически значимый отказ вон то тестит?

Такой полный отвал девайса рюхается даже глупым классическим райдом. И в реальном случае бенефит вообще в чем? При редком постепенном вероятностном развале, характерном для текучек и сыпучек (FEC не справился, фирмварь решил вернуть "уж что вышло" вместо IO error) - btrfs ничем не хуже работает, чинит чексумы и вопит в dmesg. И так то выживает даже на откровенном трешаке где ext4 ушатывается менее чем за месяц.

И еще мне не совсем понятно - если будет как бы тот же девайс на вид, но де факто совсем другой уже, может даже с чем-то нужным, как оно определит: можно ли туда вообще писат и его ли это девайс вообще? Не то чтобы проблемный кейс просто случайно создать но в случае btrfs я понимаю как это: на девайсе 3 копии суперблоков, в них UUID фс и generation, так что можно проверить и что это наша ФС и что девайс не выпадал надолго, фатально отстав от эволюции состояний пула. А вон то как избегает факапов в таких случаях? Оно не сможет "похожий" девайс присвоить при случае и развандалить? Та же нумерация девайсов при сканировании может меняться, скан асинхронный и параллельный нынче - "кто первый ответил тот и /dev/sda", грубо говоря.

> а после ресилвера вовсе как новое стало.

Да это то понятно. Btrfs после полного scrub сыпучки тоже все утекшие регионы чинит на ура. Как и при просто натыкании на это при чтении.

> Потеря суперблока на 1 девайсе не помешала. btrfs --
> больше половины не вернуло. С рейд1 обе ФС вернули всё.

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

> Гонял виртуалку, в которой делал apt dist-upgrade и засекал время (предварительно apt
> dist-upgrade -d делал, чтоб скорость качания не влияла).

Ну да блин, звездолет не очень ловко колесит по дорогам общего пользования. Но если вспомнить что у нас гиперпространственные движки есть, в отличие от лохов в пробках...
1) btrfs sub snap <system> </mgmt/before-upgrade>; sync; (снапшотим "систему сейчас")
2) eatmydata apt dist-upgrade ... or whatever. И шел бы fsync нафиг!
3) Если 2) зафейлился по любой причине, отваливаем на снапшот "before-upgrade". Если все прокатило ну, ок, тогда...
4) после всех проверок что результат устроил - стираем снапшот. Имеет смысл немного подождать и проверить весь софт до этого.

Зачем стоять на светофорах, если можно телепортироваться в назначение? А если не понравилась материализация в фонарный столб, сгонять на машине времени в прошлое, учесть препятствие, попробовать маневр еще раз, подкорректировав чуток :)

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

Зато менеджмент всего этого становтся просто адищем.

> Во-2, каждый такой псевдо-блочный девайс может быть заснапшотен (а также send-receive можно
> делать), независимо от других. Это два технических преимущества.

У btrfs в этом плане все сильно иначе, там subvolume всего лишь поддеревья (иерархии) с независимым снапшотированием. Это никак не отражается в блочные уровни а их райд "file based" как таковой. И в их дизайне вон то не имеет особого смысла. Я так понимаю что саням этот изврат надо было потому что у них не было управления девайсами и райдов в системе и они втянули классический варианто этого в ФС. Btrfs показал что не-классический вариант когда оно на уровне именно ФС - намного круче в менеджменте, имхо.

> Ну мне если честно по барабану что там внутри.

Не, вот на минутку, вы тут вещали что должно работать быстро. Или уж должно или уж нет. Моя ремарка - о том что "нативно" такой дизайн слоупок! А то что рамдиски быстрые - никто не сомневался. Только это не достоинство ФС и ее структур. И - внезапно - не катит без сотен рамы. Если сотен рамы на ломовой кеш нет (мир на файлопомойках не кончается) - ну оно и работает понятно как. А btrfs остается юзабелен даже на тощем роутере с мизером рамы, когда я ему в usb порт какойнить переносной винч с этим цепляю.

> Btrfs просто жутчайше фрагментирует файлы под торрентами

Вообще это зависит от кучи факторов. Я качал торенты и в зависимости от преаллокации, размера частей, и свободного места результат весьма варьируется. Ну и некто iZEN в свое время то же самое на zfs смог, догнав 3-дисковый пул (правда из ноутовых дисков) до чтения "аж" 15 мегов в секунду. При том там дефрага нет и очень интересно что он потом делал с столь крутым пулом, кроме пересоздания с ноля :). Настолько ушатать btrfs у меня не получалось, хотя, ок, у меня в многодисковых пулах с механическими дисками они все ж не ноутбучные, я не настолько мазохист.

> или файл (CoW) с образом виртуалки.

Опять же - все от конкретики сильно зависит. В данном случае от поведения виртуалки. Если виртуалка активно не пишет на диск - то и похрен вообще. Если пишет часто и мелко - ну, ой, фрагментируется конечно. Частично лечится увеличеением commit = и autodefrag в опциях монтирования, но вообще, у каждого дизайна есть сильные и слабые стороны. Логично юзать сильные и избегать слабые.

> ФС), OpenZFS тут рулит просто хотя бы тем, что мельче заранее
> установленного размер блока не рассыпется фрагментами

Минимально вменяемые торентклиенты обычно обладают своим кастомным кешом, как раз поэтому, и не гасят мелкими записями такого размера. Типовые фрагменты от них это какие-то мегабайты. Ну и запись менее чем чанк торента смысла не имеет особо, а сейчас народ и 4-8 мегов юзает - для уменьшения размеров торентфайла.

> (зато сосёт полным отсутствием дефрагментатора).

Вот мне и интересно что потом iZEN с своим супер-пулом делал :)

> С другой стороны, в OpenZFS никогда не будет (по-видимому) cp --reflink=always, даже
> внутри датасета, не говоря уж о том, чтобы между ними.

Это наверное как раз из-за блоков. В случае экстентов это заметно проще получается.

> cp --reflink=always офигенно между субвольюмами "копирует" таким способом.

Да оно и в пределах subvolume отлично работает. При этом оно просто 100% дедуп копии на старте, в уровень менеждмента не отсвечивает, именно "дешевый и сердитый дедуп" без ломового жрача проца и рамы, но логически это 2 разные копии.

Очень доставляет для data recovery: мастеркопию совсем не трогаем, а fsck и прочий дестрой на ее рефлинке. При номинальном размере в терабайтах реально создается за секунды, весит по размеру дельты, т.е. обычно немного, если не получилось, стереть попорченый рабочий образ, нарефлинкать за пару секунд новый и попробовать снова. Приятно себе оверсельнуть дохрена терабайтов под якобы-копию. Можно итеративно допинывать многотерабайтную чушку до кондиции не ожидая часами копирования и без мега-сторажей на 100500 терабайт, хранилка чуть больше образа нужна. А, надеюсь это объясняет почему возможность подоткнуть на время девайсов для расширения мне иногда полезна, а потом вынуть их и реюзнуть под иные цели.

> В целом каждый раз приходится выбирать, btrfs или openzfs. И пока *у
> меня* получается так, что под рут или под хомяк, если нет
> необходимости виртуалки гонять -- btrfs, для виртуалок или для файлопомойки/NAS на
> рейдах -- openZFS.

Ну вот для файлопомоек в чистом виде zfs с его свойствами вполне ок... там обычно память все же не совсем мизерная, жрать ее особо некому, блочная природа дизайна не очень икается, соответственно. Но считать block based дизайн фичой относительно extent based я чисто технически отказываюсь, в целом скорее все же анти-фича. Ну вот не осталось желающих юзать блочные дизайны вместо экстентов в современном мире, что намекает.

> (рейдz2) оказался основным :) Но конечно бтрфс наверное бы переехала одним
> balance тут.

Ну да, если места хватит - он это так делает: читает block group в старой схеме. Записывает в новую BG, с новой схемой, определяя чье это по backrefs. Апдейтит метаданные указывать на новый вариант. Освобождает старую BG. При чтении фиолетово в каком типа BG данные лежат, если половина в старой схеме, половина в новой - и похрен. Я даже крешил пару раз конверсию. Ну, после ребута возобновлял это дело да и дело с концом. Ничего не дохло. А вот с более классическими дизайнами я б так не рисковал - они откуда вообще знают прогресс конверсии допустим и как его возобновлять? Этой то штуке все просто - опять сканим bg в разбираемой схеме и переписываем их в новой, пока этого типа bg не останется. Т.к. cow-записи недеструктивные факап даже не портит данные по идее.

В принципе оно могло бы вообще хранить несколько типов BG для данных и по каким-то критериям более ценные данные так, менее ценне этак, просто этой логики нету в аллокаторе. Но сам дизайн мог бы даже такое. Это же позволяет мягкую конверсию, когда запрашивается новая схема отличная от старой и новые блоки идут в этой схеме, а старые так лежат в предыдущей. При этом можно "плавно" конвертить, операция оказывается дефернута в стиле cow.

> Уже несколько лет как, с 2.0.x версий кажется. Работает, проблем не доставляет
> кроме каких-то особо странных случаев типа send/receiv'а из нешифрованного сорца в
> шифрованный дестинейшн.

А он это не чекает? Собссно btrfs fscrypt не сделал еще и потому что это странновато взаимодействует с мультиреференсами экстентов в _разных_ файлов, в fscrypt такое изначально не предусмотрели - для более простых фс делали. А совсем кастом они кажется не хотели, т.к. в принципе у fscrypt идея достаточно простая и как "менее параноидальное" шифрование вполне недурно смотрится.