> ну так тебе "важно работать", или где?

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

> Если это васян-локалхост, то постоит, пока его чинят.

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

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

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

> Поэтому и ссылки что "у пейсбука все работаит" - актуальны только для
> конкурентов пейсбука с теми же деньгами и подходом.

А вот и фиг. Фэйсбук с их юзкейсами неплохо прозвонил core системной механики файлухи. И неизбежно обезглючил его. Да, RAID56 это конечно не поможет - фэйсбук таким не пользуется в силу специфичных, скажем так, свойств и грабель RAID56 как технологии.

> Ему a) плевать на сохранность котиков

Неверно. Акционерам вовсе даже не плевать на отток юзерей. А если котиков пролюбливать - отток будет. Кто же будет грузить котиков только для того чтобы из пролюбили, аннулировав усилия? :)

> b) он то что ему ценно - обеспечивает дублированием и при том многократным, а чинить
> ничего не будет.

Не подтверждается git log, где чуваки с @facebook.com делают этсамое, бида-бида :P.

> А твой десктоп может и подождать твоего внимания.

А потом меня контрактор отымеет за слитые сроки и я получу меньше профита да еще обтеку репутационно. Оно мне надо? Я на линухе в отличие от др@черов локалхоста еще и работы работаю.

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

Не, я таки упер у энтерпрайзников ряд технологий показавшихся мне клевыми.
1) Я попробую откатить снапшот. Круто, быстро, через минуту все будет ЗБС, это обычный системный факап а не кончина блочного девайса.
2) Если не прокатило, ну, шыт, грузимся с бутявки, перераскатываем image системы, при том не raw а btrfs receive, который сильно компактнее и весь по делу. Минут через 10-15 будет как новое.

Что я, ламер все с нуля переконфигурять и софт 2 дня переустанавливать? :)

> Все так делают. Полный бэкап обычно не по карману и не по времени.

Я не заметил в btrfs send / (system) и /home (userdata) чего-то сложного, дорогого, да и места оно весьма умеренно. На внешний 2-терабайтник для бэкапов такого навалить можно еще несколько сотен раз и все-равно место останется.

> ну так копии суперблоков у нас - с 74го года.

Ну так там больше чем копии суперблоков. Нечто типа альтернативных view структур ФС. Чем тебе поможет копия суперблока если какое-нибудь описание экстентов ушло в астрал? А в btrfs этого самого можно попытаться из разных мест добыть, в надежде что GC еще не пришел за вон тем и вон этим и оно дескать вот с той точки возьмет да и распарсится. Это ж CoW - и он by design содержит некий ассортимент состояний, поскольку новое - "поправка" на старое, без разрушения старого. И если вон там не сработало, можно сгонять немного назад в прошлое и может быть сработает там. Или там. Или там. А в EXT состояние только одно. И если это не сработало - УПС. Приплыли, наш друг hex editor. Ну еще testdisk и photorec, однако результат в любом случае очень далек от идеала и многократно больше долботни чем если автоматический парсер смогет нащупать относительно валидные версии деревьев "на пожевать".

> Только очень редко помогает - настолько редко, что в ext4 число этих копий
> урезали на пару порядков.

Ну так правильно. Суперблоки далеко не все метаданные в ФС, мягко говоря. А как насчет собственно фактического описания размещения файлов? Это уже нифига не в суперблоке, и если это пролюбить то и файлы не прочитаются уже, только хексэдитором в ошметках копаться :P

> Целее будут и меньше обновлять критичных структур на каждый чих.

Палка о двух концах. На btrfs я при жестком зависоне контроллера флехи разок лишился 2 из 3 суперблоков. Ну вот сгруппировал падло что-то, стер большой erase block - и в этот момент повис. Профакав прилично хлама за присест, видимо (весь erase block/erase group который кантовал). Из третьей копии починилось, но вообще - close call. Остальное DUP ессно тоже зафиксил, куды он денется.

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

А таки у меня и на лаптопе бэд разок вылезал, в аккурат под метаданными. Было очень кстати что btrfs пробурчал "CSUM ERROR, corrected" вместо того что за этим обычно следует :). А в одноплатнике SD карта через годков 5 вот весело сыпанулась под libc6, и какая мне радость что это "всего 1 сектор" если оно не грузится и я подрываюсь в перди это устранять? :)

> CoW не панацея и не 100% - те самые точки входа статичны,
> иначе их невозможно будет найти -

Суперблоков опять же более 1 копии, для начального понимания чего это у нас такое вообще.

> где-то должна лежать таблица со ссылками на таблицы текущих актуальных блоков.

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

> И обновлять их приходится точно так же как старинные суперблоки - все
> чохом. Ничего принципиально нового.

Нового то что в результате в дисковых структурах есть некая избыточность, которую не подгреб GC. Это дает больше шансов относительно успешно распарсить основные деревья, более-менее полно и автоматически вычитав большую часть данных. А в ext4 если вон тот набор метаданных не прокатил, это полный и окончательный финиш - дальше только хексэдитор и прочие photorec'и.

Так что на мой вкус, с учетом склонности к системокрушильным делам, странным экспериментам и дата рекавери, btrfs пока-что весьма приятно себя показывал, как по мне. Я имею заметить что те кто его делал - понимали что и зачем делают. И были неплохо в курсе failure modes железа, в отличие от всяких академиков.