> На нормальных ФС они вникуда не улетают. После гибернации ноутбук не проснулся.

Вообще-то при этом буфера сбрасываются и проч. Возможно в этот момент пошло что-то очень сильно не так - и память вынесло настолько что аж "ноутбук не проснулся".

В нормальном железе с безглючным low level софтом - вон того не бывает.

> Скорее всего, оно по какой-то причине его полностью решило пересобрать или
> не знаю, как так вышло, а на барьеры дешевым девайсам плевать бывает.

Судя по тому что ноут вообще не проснулся - я бы скорее поставил на то что у вас RAM крепко порушился, и что там в ФС записалось, возможно при сбросе буферов - ктулху б его знает.

> Нет, у меня была система AMD+AMD. Тут косяк был именно в самой ФС.

Это очень храброе утверждение для ситуации "ноут не проснулся", намекающей что что-то довольно конкретно обломалось где-то на системном уровне.

> Вот в ядре 6.7-rc* корраптилась ext4 после гибернации (уже на
> другой системе), но перезагрузка штатная и fsck решала.

Это видите ли когда как. Везение имеет свойство заканчиваться.

> Счас вроде как все работает по уму, но я продолжаю наблюдать. Подозреваю, что если
> бы это был btrfs - с данными я бы попрощался.

На btrfs в случае чего как-то больше опций потрепыхаться - запись изначально недеструктивная, это давет возможности опробовать разные варианты с использованием чуть более старых версий деревьев и проч. А в EXT4 если что-то не то запислось - упс, никаких старых версий и альтернатив, картина репина приплыли. И если fsck не выдюжил или полегло много...

>>, т.к. ему все пофиг а рассыпавшиеся файлы - ваши проблемы.
> Ну вот хардвар в порядке был и на xfs/ext4/zfs небыло проблем

Если хардавар не выходит из хибернации - он не в порядке. Если рушится EXT4 - тоже что-то идет не так.

> - разобраться во всех его кишках было очень проблематично).

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

С другой стороны дизайн btrfs я более-менее раскурил. Bcachefs субъективно более хаотичный и там меньше архитектуры. Но общие core идей слизаны с btrfs.

Хитрец Кент думал что ща он отломает backrefs, снизит оверхед, перфоманс и втопит... реалии, конечно, оказались чуть прозаичнее. Перфоманс у bcachefs пока не чемпионский, фороникс даже уже померял чутка. А без backrefs операции связанные с троганием данных из логического смещения (ремув девайса, ряд сервисных операций и проч) - таки тупят и вон там Кент уже задумался что какой-то индекс нехило бы. Если его в рантайм строить это ессно просадит перфоманс. А если "когда потребовался" - это роняет перфоманс операций менеджмента. Такой вот tradeoff.

> Я к чему. BTRFS хорош, но если мы потеряем b-деревья вот так
> - то RAID становится бесполезен.

На RAID так то обычно и деревья (и вообще метаданные) в минимум 2 копиях. Если конечно данные факапнулись в памяти еще до того как в RAID отреплицировано - против такого лома приема конечно нет. Но с "ram corruption" что угодно дохнет, и я не только видел прецеденты но и данные с такого рекаверил, довольно неудобно ибо там обычно живого места нет.

> И, собственно, вопрос: а метаданные там зеркалятся? По какому принципу?

По какому настроите! Хоть RAID1C4 (4 копии) - если девайсов на это есть и увеличение вчетверо не парит. Но такой хардкор имеет смысл имхо на конфиге с ECC, и заведомо стабильной системе.

У btrfs могут быть разная схемы для данных и метаданных, более того - можно на ходу рестрайпнуть, это даже относительно безопасно благодаря логике CoW (у меня как-то powerloss был на компе где я конвертил схему).

У bcachefs примерно та же идея. Кент передрал эту клевую идею. Воон там выбирается число копий и данных, и метаданных. В mkfs - точно. В рантайм, как в btrfs, переигровку реплик - пока не пробовал с ним, но вроде тоже можно.

> Да и с raid1 замена диска - печаль:
> Device removal must satisfy the profile constraints, otherwise the command fails.

Можно грубо отключить и перестроить из degraded - но "плавный" вариант намного лучше, если девайс живой, но его хочется вынуть, лучше btrfs device add нового, и потом remove старого. С него будут удвинуты данные - в том числе и на новый.

Де факто оно позволяет даже очень странные вещи, типа замены диска под работающей системой. Тоже обыгрывается как add нового -> remove старого, и там подшаманить профайл метаданных как раз придется - оно заметив второй диск радостно RAID1 для метаданных начинает юзать. Это немного клещится с планом вон тот девайс отобрать. Но решаемо конверсией профайла метаданных. Если кто захочет это повторить - не забудьте бутлоадер и загрузочные флаги на новом накопителе, иначе можно будет немного обломаться.

FS UUID при этом фокусе не меняется, так что менять монтирование рутфс и проч не надо.

> Ну и вообще вот с профилями и, соответственно, странными дефолтами при формате
> в тот же RAID0 можно здорово обгадиться при конверте в RAID10.

В btrfs мало чего прибито на гвозди. Схему хранения для данных и метаданных можно переиграть по желанию, прям на ходу. И это безопаснее чем в других штуках. Оно аллоцирует данные в чанках, у чанка есть "схема хранения".

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

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

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

В нормальном железе с безглючным low level софтом - вон того не бывает.

> Скорее всего, оно по какой-то причине его полностью решило пересобрать или
> не знаю, как так вышло, а на барьеры дешевым девайсам плевать бывает.

Судя по тому что ноут вообще не проснулся - я бы скорее поставил на то что у вас RAM крепко порушился, и что там в ФС записалось, возможно при сбросе буферов - ктулху б его знает.

> Нет, у меня была система AMD+AMD. Тут косяк был именно в самой ФС.

Это очень храброе утверждение для ситуации "ноут не проснулся", намекающей что что-то довольно конкретно обломалось где-то на системном уровне.

> Вот в ядре 6.7-rc* корраптилась ext4 после гибернации (уже на
> другой системе), но перезагрузка штатная и fsck решала.

Это видите ли когда как. Везение имеет свойство заканчиваться.

> Счас вроде как все работает по уму, но я продолжаю наблюдать. Подозреваю, что если
> бы это был btrfs - с данными я бы попрощался.

На btrfs в случае чего как-то больше опций потрепыхаться - запись изначально недеструктивная, это давет возможности опробовать разные варианты с использованием чуть более старых версий деревьев и проч. А в EXT4 если что-то не то запислось - упс, никаких старых версий и альтернатив, картина репина приплыли. И если fsck не выдюжил или полегло много...

>>, т.к. ему все пофиг а рассыпавшиеся файлы - ваши проблемы.
> Ну вот хардвар в порядке был и на xfs/ext4/zfs небыло проблем

Если хардавар не выходит из хибернации - он не в порядке. Если рушится EXT4 - тоже что-то идет не так.

> - разобраться во всех его кишках было очень проблематично).

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

С другой стороны дизайн btrfs я более-менее раскурил. Bcachefs субъективно более хаотичный и там меньше архитектуры. Но общие core идей слизаны с btrfs.

Хитрец Кент думал что ща он отломает backrefs, снизит оверхед, перфоманс и втопит... реалии, конечно, оказались чуть прозаичнее. Перфоманс у bcachefs пока не чемпионский, фороникс даже уже померял чутка. А без backrefs операции связанные с троганием данных из логического смещения (ремув девайса, ряд сервисных операций и проч) - таки тупят и вон там Кент уже задумался что какой-то индекс нехило бы. Если его в рантайм строить это ессно просадит перфоманс. А если "когда потребовался" - это роняет перфоманс операций менеджмента. Такой вот tradeoff.

> Я к чему. BTRFS хорош, но если мы потеряем b-деревья вот так
> - то RAID становится бесполезен.

На RAID так то обычно и деревья (и вообще метаданные) в минимум 2 копиях. Если конечно данные факапнулись в памяти еще до того как в RAID отреплицировано - против такого лома приема конечно нет. Но с "ram corruption" что угодно дохнет, и я не только видел прецеденты но и данные с такого рекаверил, довольно неудобно ибо там обычно живого места нет.

> И, собственно, вопрос: а метаданные там зеркалятся? По какому принципу?

По какому настроите! Хоть RAID1C4 (4 копии) - если девайсов на это есть и увеличение вчетверо не парит. Но такой хардкор имеет смысл имхо на конфиге с ECC, и заведомо стабильной системе.

У btrfs могут быть разная схемы для данных и метаданных, более того - можно на ходу рестрайпнуть, это даже относительно безопасно благодаря логике CoW (у меня как-то powerloss был на компе где я конвертил схему).

У bcachefs примерно та же идея. Кент передрал эту клевую идею. Воон там выбирается число копий и данных, и метаданных. В mkfs - точно. В рантайм, как в btrfs, переигровку реплик - пока не пробовал с ним, но вроде тоже можно.

> Да и с raid1 замена диска - печаль:
> Device removal must satisfy the profile constraints, otherwise the command fails.

Можно грубо отключить и перестроить из degraded - но "плавный" вариант намного лучше, если девайс живой, но его хочется вынуть, лучше btrfs device add нового, и потом remove старого. С него будут удвинуты данные - в том числе и на новый.

Де факто оно позволяет даже очень странные вещи, типа замены диска под работающей системой. Тоже обыгрывается как add нового -> remove старого, и там подшаманить профайл метаданных как раз придется - оно заметив второй диск радостно RAID1 для метаданных начинает юзать. Это немного клещится с планом вон тот девайс отобрать. Но решаемо конверсией профайла метаданных. Если кто захочет это повторить - не забудьте бутлоадер и загрузочные флаги на новом накопителе, иначе можно будет немного обломаться.

FS UUID при этом фокусе не меняется, так что менять монтирование рутфс и проч не надо.

> Ну и вообще вот с профилями и, соответственно, странными дефолтами при формате
> в тот же RAID0 можно здорово обгадиться при конверте в RAID10.

В btrfs мало чего прибито на гвозди. Схему хранения для данных и метаданных можно переиграть по желанию, прям на ходу. И это безопаснее чем в других штуках. Оно аллоцирует данные в чанках, у чанка есть "схема хранения".

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

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

На самом деле эти звездолеты с машиной времени довольно просты в пилотировании - после того как основные принципы поймешь. Да, это отличается от классики. И только. У Кента на мой вкус управление пока немного хаотичнее но в целом по образу и подобию, ибо общие идеи такие же. С прикручиванием к bcachefs-like идее, что так то добавляет аспектов в управлении.

У кента можно нарулить иерархическую хранилку - с записью на быстрый буфер и медленным реплицированием с него вооон туда, и кешированием "горячего" на быстрый носитель. Но при этом в отличие от bcachefs оно явно в курсе реплик и их состояния. Так что вероятно будет несколько лучше bcache - который легко убивает файлухи наповал как только быстрый накопитель затерся.