> А если неоткуда, ...то чего вы ожидали? Однако даже на единичном механическом диске оно кладет metadata с схемой хранения DUP по дефолту. Разок спасло меня от случайного бэда на лаптопном винче, попавшего по счастью в метаданные. А в случае EXT4 если бэд под метаданные попадет...
> btrfs рассыпается и теряет все данные, даже если там один бит флипнут.
Скорее EXT4 так делает. Не имеет механизмов обнаружения таких проблем, не говоря о парировании. Так что если btrfs в такой ситуации имеет шансы, особенно если к этому заранее подготовиться (=DUP для данных и метаданных), то ext4 становится тыквой. И я имел очень так себе прецедент на ремотной железке в автопилоте. Не понравилось. Выводы были сделаны.
И нет, если что - даже fsck не поможет если стораж реально подвел и libc6 не читается. При этом система тупо не взлетит. А с btrfs оно таки вытаскивает там и тут из второй копии, show goes on. И в целом это куда как более diehard может быть. Таки заменить EXT4 на btrfs с схемой DUP сильно подняло надежность забавного выводка железок (ARMовские одноплатники). И early warning о сыпучем носителе (или проблемном железе) задолго до того как это вообще создаст видимые проблемы - таки тоже хорошо.
> Никакого доверия ей быть не может, она делает что хочет сама.
Она буркнет "CSUM ERROR" в лог ядра и вытащит блок из второй копии. Не забыв перезаписать проблемный - "self heal". Клево, кстати, работает, очень помогая беспилотным системам которым никто не может уделить внимание здесь и сейчас. Удачи так с EXT4. А фанатизм это круто, но только не когда ты подрываешься чинить железку, в свое время и за свой счет.
> Ext4 не в пример более устойчивая, при повреждениях теряется только часть повреждённого файла.
Ога, если повреждение не попало в метаданные. А если попало - ну, блин, тоже фак. И файлы тоже бывают разные. Ну вот не грузится система без libc6, хоть тресни. И дальше радости то с того что это 1 файл? Система при этом вообще совсем тыква.
> У тебя кстати тоже не совсем правда,
В смысле?
> в ext4 есть инлайнинг, и данные могут хранится прямо в
> журнале (бонусом повышение производительности).
Вообще-то inline это не про журнал, а про хранение прямо в метаданных ФС, если файл мелкий. Позволяет не делать лишнее обращение из региона метаданных в регион с данными, ускоряя работу с мелкими файлами и до некоторой степени уменьшая slack. Так умеет и btrfs и ext4 по состоянию на сейчас.
> Вроде тот парниша проверял тогда, что с случится при повреждении журнала в такой ситуации,
У btrfs понятие журналирования ... нечто специфичное. Это CoW и в целом там все здорово иначе.
> и btrfs рассыпалась самой первой (без возможности восстановления вовсе).
У нее есть на самый крайний случай offline вычитывалка без монтирования, парсер прямо в тулсе "btrfs". Так что там можно довольно круто потрепыхаться даже в совсем тухлых случаях. На манер коммерческих тулсов для вычитывания ntfs, только сразу частью тулкита ФС. И нет, для ext4 такой штуки нет. Во всяком случае в штатных тулсах. Правда там fsck неплохо справляется. Но только до известных пределов.
> Reiserfs (3) второй, и ext4 оказалась самой устойчивой к повреждениям.
> Ей вообще пофиг, что там записано что-то другое.
Угу, только когда libc6 не прочелся с системного стоража - системе малость не пофигу, она работать не может при этом :)
> Судя по этому, видимо чексумминг не был включен. Неконсистентность
> в ext4 подразумевает что вместо новой копии файла, fsck найдёт только старую.
Поскольку обычно EXT4 юзают с журналом только метаданных, ничему не противоречит получить полуперезаписанный файл состоящий из нового начала и старого хвоста. По метаданным это консистентно, однако то что программы смогут работать с таким файлом - ниоткуда не следует. В классическом дизайне для журналирования данных надо писать данные дважды, что тормозно. Весь пойнт CoW в том что он это обходит нахальным жульничеством - у него по сути только журнал и есть, а область с данными в которую коммитят - ее нет. Взамен возникает нужда в GC который будет подбирать старые блоки, иначе место таки закончится.
> нарастание урона, либо блоки будут помечены "грязными" и с ними ничего
> не случится. Но зависимые блоки изменятся со временем.
Спасибо, но я на своем окороке не так давно познакомился с развалом EXT4 на сыпучем носителе. И даже то что там что-то читалось было слабым утешением для системы которая не может загрузиться. Особенно учитывая что это был армовский одноплатник.
> Пс. рейд никакого отношения к ext4 не имеет, это разные уровни. В
> zfs и btrfs просто впихнули всё в кучу.
Btrfs вполне можно засунуть даже на единичную SD карточку с схемой DUP. Не то чтобы с EXT4 совсем нельзя сколхозить эквивалент, но RAID придется мануально создавать на паре разделов самому и чексум все равно не будет так что толку мало.
