> или наоборот - внезапному облому там, где банальная ext4 ну потеряла бы
> может последнюю запись.Он к этому не склонен, так что на себе я это ни разу не ощутил, хотя пробовал довольно странные извраты. Зато был "инверсный" кейс, когда btrfs спокойно живет на сыпучей карте, если DUP для данных сделать. Изредка матерится на CSUM ERROR, чинит, и все работает. А ext4 довольно быстро превращается в тыкву. Ну, блин, попадет вот так бэд под libc6 - и все, фаталити, 100% unbootable. Ну вы там можете в initrd потрепыхаться если он был, конечно, но вообще система при этом 100% тыква. А btrfs при этом скажет CSUM ERROR, вынет блок из второй копии и дальше поедет. И теорвер внезапно работает уже на нас а не против нас - шанс что два бэда одновременно накроют именно один логический блок дважды - микроскопические.
> Поскольку объем затрагиваемых этой записью критичных структур - в два десятка раз выше.
Да ну бред. И если уж на то пошло, ext4 в типовой ситуации вообще gives no crap на тему участи данных - он их вообще не журналит! А если таки журналить еще и данные - вот там мы уже и поговорим о том у кого там во сколько раз скорость записи :). Чо-чо, ext4 проседает ВДВОЕ из-за записи сперва в журнал, потом на диск? CoW нужду так делать таки обжуливает красивым трюком. Правда за него конечно воздается другими приколами, но вот именно это все же отпадает :P
> И что делать при рассинхронизации копий - знает только шибкоумный алгоритм.
Это в RAID+EXT как раз проблема: даже если у нас и было 2 копии, мы при несовпадении не знаем какая верная! А вот btrfs посчитает CSUM и ... возьмет блок с верной чексумой! Отбросив кривой. И вот так он чинит RAID/DUP/... куда как осмысленнее. Это очень хорошее, разумное, и отлично работающее на практике расширение идеи RAID. В отличие от гольного RAID оно нормально относится и к случаю когда накопитель не сдох совсем, но изредка сплевывает какую-то труху (условно назовем ситуацию "bad sectors на диске"). Обычные RAID в этих допущениях, внезапно, рушат данные.
> не, не будет. Будет пачка оторвавшихся inode, и скорее всего ты найдешь
> свои файлы в lost+found, может с потерянными именами и неправильной длинной.
На самом деле рандом тот еще. Может быть от нифига (ну там htree перестроил и все заверте), до дофига, с разлетом дочерта файлов и в lost+found только половина от желаемого, остальное просто в ауте и таки хэксэдитор. А кто вам сказал что я убитые EXT'ы не рекаверил? =)
> чтоб вообще увидеть что-то ценное попавшим в lost+found
Мне вот как-то раз свезло - бэдсектор на SD карте просто попал под libc6 на одноплатничке. Система (автопилотная индустриальная автоматика) от этого и стала тыквой. Ну я с досады и запилил образа где вместо этого крапа btrfs да еще DUP. Это конечно ополовинивает емкость карты, но там системы мелкие и так намного живучее в автопилоте получается. Не говоря о том что при осыпании стоража early warning в виде CSUM ERROR случается задолго до того как система фактически превратится в тыкву: проиграть теорверу "2 бэда попали на 1 логический блок" очень трудно.
> ну так как-то вот.
Ну так как-то вот вылетит туды системный файл и система тыквой станет. Или вон просто бэд всрется. Одного достаточно, если это под libc6 :P. А в btrfs это ну вообще не трабла, из второй копии починится.
> А с данными - в большинстве случаев пользы от лишних контрольных сумм
> много меньше чем вреда -
Не соглашусь. Они отлично детектят проблемы еще на подлете. Будь то глючный проц, оператива или сыпящийся стораж, вопли CSUM ERROR заставляют обратить внимание на проблему. А в EXT к моменту когда все это будет замечено половина файлов уже может быть трухой...
> потому что лучше потерять аж целый один бит в 6гиговом видео (и скорее всего ты даже не
> узнаешь об этом), чем потерять файл целиком, потому что вредная fs
> говорит - "вах, ашипко, ашипко - у меня чексам не сошлась, не отдам тебе данные,
> я лучше знаю, отдавать или себе придержать пока".
Так обычно не бывает. Reason: накопители - БЛОЧНЫЕ устройства. Первая линия обороны - FEC сектора диска/SSD. Если он не выдюжил, накопитель вернет или IO ERROR для всего блока и вообще блок не отдаст, либо, более подлый и неочевидный вариант, выгрузит какую-то труху. У современных винчей и SSD блок один черт те же 4К в типовом случае и если не идиотничать (align FS -> физические блоки) - усиления разрушений не будет. Что так блок пролюблен, что эдак. Только вот btrfs видите ли получив CSUM ERROR может блок и из второй (и вообще энной) локации взять, если это было. А вот ext4, даже с RAID, при этом несколько пролетает. Даже если несовпадение и видно - а кто без чексум знает какая копия правильная?! :D
> (А она может не сошлась потому, что бит поплыл в памяти, и
> неправильно посчиталась как раз сумма, а данные-то в порядке)
Ну да. До кучи btrfs неплохой memtest. Я как-то гонял его на такой системе специально. Данные особо не бьются, а RAID1 или DUP еще и чинит блоки. Успешно, кста. Не знаю убьется ли он такой в конечном итоге через дофига времени, но в целом это намного лучше чем то что EXT может предложить. Хотя-бы потому что мы видим что у нас проблемы в железе.
> При этом ценные данные лучше проверять самому - причем fs тут ничем
> не поможет, только помешает излишним "умом".
Если данные были ценные, стоило RAID1 какой сделать, чтоли... и вот там у btrfs никаких проблем с пониманием какая копия верная не возникает :)
> Чексаминг данных нужен только в случае когда данные изначально хранятся с избыточностью,
> и в сомнительных случаях можно взять и просто использовать верную копию.
> md raid, вроде бы, даже это умел без посторонней помощи, но
> решение явно для исключительных случаев, а не для всех.
Блабла прикольные. Но на практике - имею заметить что технология работает. Детектит проблемы железа, фиксит ашипки если есть откуда - и EXT'ам до такого integrity и health check как пехом до пекина. С EXT о проблеме узнаешь когда оно уже внезапно прилетело в табло.
