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