> Бывает всякое. Да, накрути ECC-память, диски с суперконденсаторами,
> да строго соответствующие спецификации и т.п. А надо, чтобы работало на обычном
> консьюмерском железе, которое исправное, но вот может не успеть, например,
> сбросить кэш при выключении при некотрых специфических условиях.Глядя на Unsafe shutdown count == 102... ну, вот, за 102 попытки на этом SSD не сдох вроде :). А должен? Тем не менее - если буфера не скинули, команду на шатдаун накопителю тоже поди не послали. А так и весь eraseblock/erase group можно профачить, а то и таблицы транслятора.
И ни 1 ФС не готова к тому что слетит 64-128 мегов или сколько там erase group - который in flight когда вы там питание грохнули без подачи команды на шатдаун. Имеет право слететь без подачи такой команды - накопитель сам внутрях GC и проч тоже гонял.
> И то, что ФС потеряла b-дерево > и не смогла обратитсья к предыдущей его копии -
> это, таки, настораживает, бо в суперблоке должна быть ссылка и на старые
> и на новые данные.
А там что, RAID не было и даже DUP? Что за ошибка была? В суперах ссылка на последнее консистентное состояние. Но есть опции монтирования с попыткой заякориться за другие деревья на случай если хрень все же почему-то случилась. Это не есть нормальная ситуация, потому - мануально.
> "не проснулся" в данном случае означает, что он тупо завис после выхода
> из гибернации на картинке логина.
Я бы дал 50/50 что в RAM какая-то труха образовалось.
> И это не говорит о том, что RAM порушилась, т.к. после реинсталла
> ОС и на другой ФС этот же ноут отработал ещё 5 лет без единого сбоя,
> пока его кофе не напоил.
А это все в каком году и с каким кернелом было? Я просто про более-менее современные версии, скажем, ядра 6.x - а что там в 2.6.32 было я и не знаю, ибо в курсе что бесплатный сыр достается второй мышке, надо просто подождать :)
> Я же не зря выше оговорился, что проблемы у нее будут на
> "не дорогом консьюмерском" оборудовании.
Я ее гоняю на самом разном хардваре. Очень интересно, где обещанные проблемы?
> Косяк ФС в том, что она при COW не сохраняет ссылку на копию метаданных,
Есть опция монтирования usebackuproots, вообще-то.
> записанную ранее и не может отреплеить журнал.
У нее почти нет журнала в привычном понимании, так, зачатки минимальные. Но если с ними проблемы, опять же - опция монтирования есть чтобы забить на реплей.
А в целом - cow никуда прошлые состояния не девает и при крахе по сути просто игнорит то что записано но - "указатели еще не перевешены" и этого как бы никогда не было. Неплохо работает вроде.
> Т.е. у нас фактически запись не прошла и мы не можем смонтироваться -
> так надо реплеить журнал, которого не оказалось, вместе с b-деревом.
В btrfs записи недеструктивные, на минутку. Так что красивая теория но не про btrfs.
> кто понимает структуру этой ФС на уровне разработчиков - все бы оттуда вытащилось.
Да там небось как максимум надо было nologreplay и/или usebackuproots. Правда кто вас знает в каком это году...
> Это разница в подходе. Когда ext4 обнаруживает, что crc в метаданных не
> совпадает - оно начинает ругаться и прекращает всческую запись,
А на данные - он класть вообще хотел. С прибором. Основной регион - это данные. Более того, если метаданные не прочлись, ну там бэд или труха с накопителя, EXT4 ловит нехилое фаталити. Плана на этот случай совсем нет. И никаких копий метаданных тоже. Так что урон очень даже.
Btrfs даже с 1-девайсной конфигой хранит метаданные в схеме DUP, и чаще всего может вынуть их из второй копии. На этом фоне EXT4 - как бы это сказать? Они CRC там не от хорошей жизни сделали, но в случае RAID например они не смогут умно читануть вторую копию с исправной версией. Если райд diverged - что хотите то и делайте, во! Хитрый план! Но мне btrfs'ный план ака читануть вторую копию, починить из нее убитую - нравится больше. Кенту этот план тоже по вкусу.
> BTRFS в аналогичной ситуации проблем не заметит,
Да неужели? У него чексумы на вообще все, и на метаданные, и на данные.
> т.к. она их замечает только при очередном scrub.
Булшит, оно замечает (и даже чинит в фоне, если есть откуда) при любом чтении.
> Больше секса без видимого результата. Могу и по пунктам, но ext4 _значительно_
> проще в силу того, что btrfs всё же CoW.
Он не только проще - но и фатальнее при отклонениях от идеала. Избыточности нет, возможности умно ей пользоваться даже если RAID и был (прицельно перечитать блок метаданных с второй копии) - тоже нет. Это динозавр. Плевавший на данные пользователя - чексум данных нет, а полный журнал конечно есть но это для совсем мазохистов.
Никто более не проектирует ФС по этому паттерну. Его время вышло.
> И сырые данные с BTRFS восстановить почти не возможно, если будет утеряна
> структура ФС в силу CoW (упс).
Чтобы вообще совсем снести весь btrfs в ноль надо нехило потрудиться. У него три копии суперов по зело разным смещениям, возможны разные точки входа в деревья, офлайн-вычитывалка в комплекте которая умеет вот это вот. И если даже ЭТО не смогло ничего нащупать - так там наверное и от данных мало что уже есть.
И мне даже неудобно говорить что вычитка путем полного скана поверхности требует дофейхоа времени, дает много битых файлов, ведет к потере имен, и эта операция уж точно не для казуалов. А датареки за это уже прилично обдерут, т.к. довольно неудобный случай.
> Чето в моем случае этих старых версий деревьев чего-то как-то не оказалось,
А вы usebackuproots пробовали?
> а вручную дигать по диску в поисках копии данных я как бы это...
В команду "btrfs" встроен кроме всего прочего офлайн парсер на совсем тухлый случай. Man btrfs-restore в общем. Не, на ext4 такого тула нет. Во всяком случае штатно и под линух. Под винду на нтфс сторонние утили с своим парсером - да, но это сторонние проприетарные коммерческие проги. А тут прям в родном тулките ФС. У кента кстати этого тоже нет вроде, как минимум пока.
> Данные столько не стоили. Правда теперь у меня появился
> не только бэкап, но и проверка его содержимого, ага.
А бэкап так то не лишний в любом случае. Should never happen как бы да, а бэкапы как бы вот. Потому что случаи бывают разные.
>> Если хардавар не выходит из хибернации - он не в порядке
> Софт безгрешен?
Иногда даже бывает сложно понять кто и что. Если скажем при программировании DMA автомата в адресах облажались и прострелили кернелу мозг - это софт или хард? Так можно было, проверено как минимум нвидией, и файлухи ЭТО выносит на ура :). Вон там нвидия поубиваля хомякам их EXT4 и XFSы какой-то относительно недавней версией драйвера.
> Да. В ядре 6.7 менялись некоторые механизмы, ога. Отсюда и проблема была,
> хи хи. И хардварь конкретно в данном баге ну вот вообще не при делах.
Это тоже случается. Я в контексте btrfs такое же примерно выловил и помог замочить пару ядер назад - но btrfs вообще попался только потому что рефактор его зацеплял. Вероятно и других цепляло - просто у меня были конкретные тестовые конфиги под -rc ядра где это вылезло я и отпинал бтрфсников, они доперли что это к mm/ и попинали их. Так клевый датакарапшн не прилетел на ваши бошки в энных случаях. Хотите мне еще рассказать что бывает? :)
>> Я не понимаю почему это недоразумение - замечательно.
> В сравнении с btrfs у него хотя бы аналог RAID5 работает
Ага, тут недавно была новость как там что на самом деле работает. Там где про разрушение данных если быстро делать копии копий. Заодно всплыло немало интересного как господа фичу рефлинков выкатили - включив по дефолту, для тестов на хомяках. Ну и тестанули. Test failed ахнул гентушник билдивший go.
> умеет в slog и L2ARC, оно ЗНАЧИТЕЛЬНО надежнее btrfs by design.
Нехило бы это громкое заявление технически обосновать. Особенно учитывая что недавно у господ вышел сочный факап по линии их чудных кешей. И можно я скажу что Кент кеширование на SSD намного вменяемее продумал чем ZFSный бред?
> Но формат там весьма сложен, да.
Он не просто сложен - я так понимаю что он супертормоз и это вытягивают заливанием гигазами оперативы. Не вижу с чего этим структурам быть быстрыми. Это не bcachefs. И даже не btrfs. Какая-то полублочная муть. На которую, вот, рефлинки цать лет пытались, а когда смогли, крякнул кеш.
> Не думаю, что он вот именно так рассуждал, но в отличие от btrfs он тянет лямку
> в одно хлебало. Тесты похороникса вообще с реальностью ничего общего зачастую не имеют.
Я немного сравнил с btrfs - и каких-то радикальных улучшений так с наскока не увидел. В принципе понимаемо - кенту пришлось идти на компромиссы для майнлайнинга, потом отыграет часть.
> Записываю: btrfs безгрешен и ошибок в алгоритмах иметь не может.
Может ессно. Проверено ZFS'ом недавно :). Но даже после такого фееричного обтекания вашего фетиша сватать его вам стыд глаза не ест...
> Ещё раз: даже если это был @ram corruption@ - данные должны быть восстановимы. Всё.
Откуда бы это все следует? Ну и в btrfs возможностей с этим потрепыхаться и читануть таки либо маунтом либо офлайн парсером - сильно больше чем в среднем по больнице. А выгрызать их фотореками всякими - удовольствие сильно ниже среднего. Как практикующий этсамое грю.
> ext4 имеет чексуммы метаданных, что почти сразу скажет о проблемах.
Пардон, но
1) Он нихрена с этим не сделает уже.
2) Он не парится насчет данных. А метаданные мне нужны только для доступа к данным и самоценности не имеют. И я не ок с отсутствием чексум данных, как угодно.
Примерно 99% проблем с integrity в случае btrfs - на регионе ДАННЫХ было отловлено. Так что мне трогательная забота данных - не приболела, извините. Как и весь динозаверский дизайн с фиксированой аллокацией инодов.
> Кент вон на это посмотрел и в планах коды рида-соломона прикрутить.
И оно как бы похвально, вопрос в том не познакомится ли он с комбинаторным взрывом...
> метаданные останутся в RAID0, ибо в документации это написано, но недостаточно очевидно.
Я только 1 случай знаю когда btrfs сам умничать может - если 1-девайс с DUP до 2 добавить, метаданные будут RAID1 тогда. Но это внезапно может проблемы создать, если план был второй девайс вынуть. Такая автоматика может сделать мозг. И таки совершенно валидно RAID0 для данных и RAID1 для метаданных, так метаданные будут выживать сильно лучше, а если у части данных избыточности не было - ну, досадно, но урон небольшой.
> Тваю за ногу... bcachefs родилась из bcache, а не btrfs.
Если описывать его в 2 словах это выглядит примерно как гибрид первого со вторым. Часть кода похоже вообще скопипастили 1 в 1 - обработчик "same extent" у обоих был подозрительно похожий. Дальше он конечно в свои кишки по другому уже.
> И да, число копий метаданных настраивается, но не так, как в btrfs.
Не так - но в целом идея довольно похожая. И опять же - вот - разное число копий вполне валидною. А аллокация в buckets имеет что-то общее с chunks, хотя и отличий - есть. Такое ощущение что они пытаются конвергировать к чему-то - заходя с разных сторон.
> И число данных тоже. Там каждый девайс имеет параметр durability.
> Т.е. при создании ФС указываешь число реплик для данных и метаданных и дальше
> при добавлении девайсов просто указываешь ему durability.
У btrfs унутрях в чем-то похожая идея. Для данных и метаданных есть дефолтовая схема хранения для их блоков. И в конечном итоге RAID1 это "2 копии". С3/С4 - 3 и 4 соответственно.
И мое частное мнение - кент с Durability хлебнет горя, когда умные клавы доверятся черти каким райдам, и тут окажется что обе копии было там - и это не прозрачно для ФС - так что re-read копиии с целью фонового репайра - "агащас!" и вот на ка тебе заваленый пул, золотая рыбка, ибо нефиг такое делегироватоь всякой мутной ср@ни c уровня ФС. Правда этот прострел пяток на усмотрение стрелков, но кмк - прострелы будут.
> Ты даже можешь raid аппаратный подсунуть и указать durability ему выше единицы,
Ага. А потом попробуй оттуда re-read если что-то все же ну вот не прочлось... КМК кент таки познакомится с теми кто на "кульной фиче" налетит.
> У btrfs же какаой-то секс с профилями и прочим При том - не всегда очевидный.
На самом деле примерно то же самое по смыслу. И кент секса тоже добавит с RAID56 и прочими ридсоломонами постепенно.
> Не надо говорить, что кто-то у кого-то передрал. Смиритесь, что некоторые вещи
> где-то могут быть реализованы лучше, а где-то хуже.
Кент мог смотреть на 2 дизайна - и ессно имел все шансы учесть их траблы. Но дело в том что он уже заметил что некоторые решения вон там были не просто так. Как с backrefs... :). И вот уже оказывается что Кенту и самому скорость операций менеджмента и GC - "не очень". Зато backrefs не передрал. Пока. Это разгоняет перфоманс - но при желании отменеджить эту экономию захочется проклянуть. Ибо теперь вынуть девайс - уже не так уж просто и быстро.
> Если я хочу вынуть девайс из рейда - должно быть максимум две команды
> (отправить его в статус fail, а после вынуть).
Кому должно? С чего? RAID1 вообще не должен штатно работать с 1 девайсом. Только degraded. В таком виде можно его и совсем без команд получить, выдернув накопитель.
> mdadm, LVM, ZFS это позволяют. И даже bcachefs.
Btrfs тоже. Я даже именно этот сценарий пару раз делал. А ваша вкусовщина - это ваша вкусовщина. На мой вкус вы и возитесь с вашими LVM, mdadm и ZFS. Я же предпочту без этого секса. И да, кентовская штука управляет местом "примерно как btrfs". Т.е. для нее не проблема подоткнуть или вынуть девайс и получить +N места, из-за аллокации bucket'ами. По общей логике это именно btrfs косплеит. Да, есть отличия, и все же. Оно сможет в ту же прелесть ненапряжного расширения места и ремува девайсов. Без делания мозга выравниванием и размерами. В отличие от блочных уродцев. Это то что у него как в btrfs.
> Без шаманств с профайлами метаданных. Почему в btrfs это сложнее?
Да там горе от ума походу. Ну, бывает :). Мне похрен ибо столь странная операция была нужна пару раз в жизни. При том вообще в научных целях - посмотреть, смогу я под живой системой системный девайс сменить без отвалбашки на горячую?! Мне была интересна технологическая валидация такой возможности.
Это на самом деле дает довольно интересные технологические возможности фикса системы в режиме нонстоп. Как в анекдоте где хирург оперирующий на сердце садится в авто, заводит, и говорит мужику в автосервисе - мол, хочешь получать как я? Тогда чини авто вот так, как я твое сердце. Мне было интеерсно прочекать технологическую возможность смены накопителя под ОС без ее стопора. С btrfs этот фокус прокатил.
> Да да да. Всё просто, когда знаешь. Мне вот ZFS сейчас проще кажется ;)
А мне он нафиг не упал с его внемайнлайн проблемами и античным дизайном. Штука кента - оно в майнлайне и "Gen3" идеи, совсем другой разговор.
> Общие идеи - они впринципе проистекают как раз от ZFS, если уж так судить,
Частично - да. Но у ZFS вроде как раз и нету такой "пофайловой" аллокации места на девайсах, когда можно абы какие девайсы абы как добавлять-вынимать и там аллокация места "as needed", с пофигом на выравнивания и размеры девайсов. Это довольно круто придумано и делает менеждмент простым и ненапряжным. И это уже не блочный райд, ближе к "файловому", грубо говоря, это - решение уровня аллокатора ФС, как вон то раскладывать.
Для меня это довольно четкая граница водораздела по технологиям. Либо тупой блочный RAID, либо такая вот динамическая аллокация без прогрева мозга. В ZFS разве это было?
> btrfs все же корпорации делать пытались, а не какой-то перец в одно хлебало.
Поэтому архитектуры там все же побольше. Зато у Кента задора и упорства на троих хватит. И он уже мог смотреть на чужие траблы. Это ценный козырь, так что ряд проблем btrfs он обошел. Но вероятно получит ряд других.
> Эээ... Оно их убьет наповал, если там writeback. В остальном - ничего он не сломает.
В случаше bcachefs - ему статус реплик по накопителям - и факапы их чтения - виднее будут. А на фс подпертым bcache - они феерично сыпятся когда bcachе выгружает им баааальшой блок трухи с кешового накопителя. От такой диверсии ФС могут развалиться вдрызг. И я видел эн таких случаев. Btrfs'ники обычно замечают подарки по ору в логах ДО того как все совсем уж профачится, а остальные - вот как повезет.
> именно смерть ФС при повреждении и подразумевает.
Кент крут тем что увязал реплики с кешом. Кеш стал частью логики реплик - и на него теперь распостраняются все гарантии схемы хранения. Даже если он сдохнет или вернет труху, это теперь может обработано как любой иной сбой чтения реплики.
А если работать на блочном уровне как bcache - это знание урыто на стыке уровней, нельзя осмысленный re-read и self heal сделать с другой копии вот так по простому. ФС с полными чексумами типа btrfs могут еще попытаться что-то изобразить, но получится ли это - без гарантий ибо оно не контролирует IO с копиями и успех этого маневра ниоткуда не следует. А вот если оно явно рассматривает кеша как реплику, и запрошено более 1 реплики, окей, оно сможет вынуть другую реплику вместо осыпавшейся - и проблемы как бы и нет. Ибо оно уже таки как раз может контролировать процесс.
