Вопрос про снепшоты btrfs

Не запишешь. 'No Space Left on Device'

Старые данные никуда не денутся, так что ты займешь оставшиеся 250гб и не сможешь записать еще 1гб

ИМХО для снапшотов лучше подходит ZFS, там ты просто ставишь метку и все записи в ФС после неё считаются снапшотом(Ну я так работу ZFS понимаю)

Ок, хорошо. Еще вопрос: что делают (какие действия) люди, у которых btrfs вдруг ломается и уничтожает данные?

молятся

btrfs - часть проекта linux. Плюс, она есть в федоре, а zfs - нет. Поэтому я больше к ней склоняюсь. Но вообще, конечно, мне бы попроще, поменьше возни и побольше надежности.

что-что?

там fsck завезли кстати? лет 10 назад было популярно использовать её, было весело

У современных ФС нет средств восстановления данных.
Некоторую защиту дают програмные рейды, но именно как рейды, за счёт восстановления повреждённого блока средствами рейда.

что делают (какие действия) люди, у которых btrfs вдруг ломается и уничтожает данные?

Восстанавливают данные из бэкапов. ¯\_(ツ)_/¯

там [в ZFS] ты просто ставишь метку и все записи в ФС после неё считаются снапшотом

Ты не поверишь...

восстановления повреждённого блока

Да, это почти так. Только вот нюансы. например MD не знает какая копия верна и восстановить ничего не может. Более того, он при обнаружении разницы (это только если запустить профилактичексий check), он затрет одну копию другой. При этом, насколько я понимаю, диск с которого копировать он выберет произвольно. Можешь представить, что будет если один диск начнет возвращать «мусорные» данные, вместо отказа чтения блока: он затрет этим мусор оставшуюся копию.

Я когда это понял, перестал эксплуатировать MD mirror в паре ssd+hdd, хотя до этого два года был совершенно счастлив в этой конфигурации. Почему? Потому что видел однажды (давно и вне этой конфигурации), как сбойный ssd возвращет мусор.

защиту

«защита» у меня сейчас сделана путем бекапов.

Я плохо сформулировал вопрос. Я хотел узнать, «что они такое делают, что приводит к крешу»?

например MD

В Btrfs и в ZFS есть встроенный райд, при чём в ZFS можно включить контроль чексум блоков и тогда мусор не пройдёт.
Как с этим в BTRFS не знаю.

И это конечно не отменяет необходимость создания бекапов, хотя и уменьшит число случаев когда они необходимы.

К стати есть ещё такое развлечение, как откат транзакций, который сам по себе может превратить файл в мусор, средний между начальной и конечной версией.

btrfs наверное тоже имеет чексуммы.

что до рейда, то я не очень расчитываю на btrfs raid1 потому что, насколько я понимаю, он не умеет читать только с ssd а записывать и на ssd и на hdd. (а мне если raid для root - то именно такая пара интересна). на md я этим пользовался, но btrfs вроде как не умеет.

Тогда к ZFS присматривайся, если комп мощный и поток на запись не большой то можешь попробовать fuse версию.

Но я лично весь этот функционал не пробовал, я только делал 5 ZFS рейд на 8 WD Raid edition и это было давно.

спасибо, посмотрю

Если перезапишешь все 250Гб (а не, например, только отдельные куски в файлах) - место кончится. Это верно для любого CoW, кстати.

какая копия верна и восстановить

Ого, уже появились оракулы? Почему это блок может быть испорчен, а чексумма не может? И какая из копий испорчена? Опять свидетели иеговы чексумм.
Чтобы восстановить, нужна избыточность превышающая то, что испорчено. Так сказать, закон сохранения информации.
И да, скорость надежного чтения для raid1 не может превышать скорости чтения одного диска. Потому что надо прочитать обе копии блока и сравнить.

Ого, уже появились оракулы? Почему это блок может быть испорчен, а чексумма не может? И какая из копий испорчена? Опять свидетели иеговы чексумм. Чтобы восстановить, нужна избыточность превышающая то, что испорчено. Так сказать, закон сохранения информации. И да, скорость надежного чтения для raid1 не может превышать скорости чтения одного диска. Потому что надо прочитать обе копии блока и сравнить.

Почему это блок может быть испорчен, а чексумма не может?

ну хотябы есть простой способ понять что что-то пошло не так.

Без чексуммы можно понять, что что-то пошло не так, на основании различия копий блока. Копия - это намного больше информации, чем какая-то ограниченная чексумма. Я вообще не понимаю каким боком здесь чексуммы. Чексумма максимум может использоваться как (ненадежный) ускоритель некоторых операций.

В ZFS она используется как дополнительный элемент контрля к предоставляемым рейдом средствам.
То же и в BTRFS я думаю.

Чёрт его знает.

Говорят, btrfs ломается на ровном месте. Я не сталкивался.

Но у меня и RAID5 работает отлично (и ловит тихие ошибки), хотя не должен.

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

В Btrfs и в ZFS есть встроенный райд, при чём в ZFS можно включить контроль чексум блоков и тогда мусор не пройдёт.

Как с этим в BTRFS не знаю.

Точно так же.

откат транзакций <...> может превратить файл в мусор, средний между начальной и конечной версией.

Каким образом ты пришёл к этому потрясающему выводу?

Сталкивался.
Вот прям смотрел на сообщения на экране, а потом система летела в тар-тар потому как это произошло после установки обновлений.

Вообще перед выключение или перезагрузкой ПК надо тройной синк делать.
Всегда.

Вообще перед выключение или перезагрузкой ПК надо тройной синк делать.

а также падать на колени и биться головой об пол, трижды!

откат транзакций, который сам по себе может превратить файл в мусор

Пепельница, ты знаешь что такое транзакция?

Нет, молиться надо только если тройного синка не сделал.
С синком как правило всё проходит нормально.

То что записывается в планы, выполняется и перемещается в список завершонного.

Копия - это намного больше информации, чем какая-то ограниченная чексумма.

Ты какую-то глупость пишешь, копия без чексумы - это фактически бесполезная информация - хлам.

Копия - это намного больше информации

Копия вообще никакой пользы не даёт, если она одна из двух. Вот есть у тебя две копии, и они различаются. Невозможно определить, какая из них неповреждена (т.е. верна). MD просто перезаписывает тебе одну в другую причем произвольную: нормальную версию мусорной или наоброт, как повезет.

Без чексуммы можно понять, что что-то пошло не так, на основании различия копий блока

Да он тебе отчитается, сколько было выявлено расхождений. И сколько блоков было «синхронизировано».

Без чексум raid1 из двух дисков бесполезен, если у тебя есть диски которые могут вернуть поврежденные данные, вместо отказа от чтения сектора. Кроме того, даже при трех дисках, тот же md, насколько я помню, опять не будет разбираться, а перезапишет одной (поврежденной) копией две оставшихся, т.е. 1 -> 2 и 1 -> 3.

А теперь подумай: файл в порядке (состояние 1) -> запись в файл -> fail -> откат в состояние 1. Как файл мог превратится в кашу? И дай ссылку на твой багрепорт.

Ты просто множество простейших ошибок сделал в своём рассуждении, даже объяснять лень.

Блоков и соответственно транзакций может быть несколько и откатываются не все :)

Ты какую-то глупость пишешь, копия без чексумы - это фактически бесполезная информация - хлам.

Заповедь свидетеля иеговы чексумм.

md

Это еще одна реализация raid. И это не эталон правильности, как и zfs

Копия вообще никакой пользы не даёт, если она одна из двух...

И какая копия чексуммы копии блока правильная? Не запутался еще в копиях? Или в твоей вере правильные чексуммы нашептывает сам бог на ушко? Чуешь масштаб проблемы? И как повлюяют на решение этой проблемы еще нескольких слоев копий копий копий ...?

Без чексум raid1 ...

Ответь на вопрос: где ты хранишь чексуммы? В божественном облаке? Или на тех же повреждающихся дисках?
И в итоге ты придешь к решению как в задаче о византийских генералов: для однозначной стратегии действий тебе нужно иметь больше 2/3 одинаковых копий. Заметь однозначной - это не означает правильной. Правда относительна. И чексуммы здесь не помогут.

И какая копия чексуммы копии блока правильная? Не запутался еще в копиях?

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

Закон сохраниния информации.
Чексумма - это хеш. Хеш - это отображение некоторого множества на конечное множество. А теперь вопрос: сколько бит в блоке и сколько бит в чексумме? И теперь пересчитай вероятость твоей «маловероятности».

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

Почему это блок может быть испорчен, а чексумма не может? И какая из копий испорчена?

Вероятность одновременной порчи блока и чексуммы так, чтобы они снова совпали — исчезающе мала.

И да, скорость надежного чтения для raid1 не может превышать скорости чтения одного диска. Потому что надо прочитать обе копии блока и сравнить.

Нет. Достаточно прочесть блок и чексумму любым способом и сверить их.

Я вообще не понимаю

This.

Вот прям смотрел на сообщения на экране, а потом система летела в тар-тар потому как это произошло после установки обновлений.

Багрепорт где?

Вообще перед выключение или перезагрузкой ПК надо тройной синк делать. Всегда.

Прекрати пороть чушь, ей больно.

При этом чексуммы также пишутся на те же повреждающиеся диски, что и сами блоки. Плюс добавляют ошибки от дополнительных манипуляций над данными. Прогресс ли это?

И какая копия чексуммы копии блока правильная?

Та, которая совпадает В том же btrfs блоки метаданных защищены своими чексуммами, которые в итоге упираются в суперблок. Лавинный эффект делает ситуацию, в которой они все совпадут, для всех практических целей недостижимой.

Я не верю, что люди могут быть настолько тупыми.

Чексумма не меняет данные, она только подтверждает или отрицает результат.
Восстанавливают блоки иными средствами.

Закон сохраниния информации

Оттого, что ты скажешь это словосочетание ещё несколько раз, ничего не изменится. Каким боком здесь «закон сохранения информации» (кстати, что это вообще такое)?

Хеш - это отображение некоторого множества на конечное множество. А теперь вопрос: сколько бит в блоке и сколько бит в чексумме?

Дело не в количестве информации, а в том, что при изменении одного бита входных данных изменится >50% бит чексуммы.

И теперь пересчитай вероятость твоей «маловероятности».

Лучше сам пересчитай вероятность того, что одновременно с повреждением одного бита в области данных повредятся ещё несколько десятков бит в (значительно меньшей) области соответствующей чексуммы (причём именно тех, которые нужно).

Багрепорт где?

ZFS держал много лет назад.

Лавинный эффект делает ситуацию

Это может дать эффект - если «лавина чексумм» будет сравнима с необходимой избыточностью для опредления/восстановления повреждений. То есть еще один огород поверх рейда. При этом у рейда есть теоретическая база, а у свидетелей чексумм - заповеди.

Ещё раз пишу, чексумма это не средство восстановления информации, а средство проверки целостности.