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

Каким боком здесь «закон сохранения информации»

Информация и термодинамика связаны через энтропию.
Нвверно этот закон из термодинамики и просочился.

И сколько нужно избыточности для опредления целостности? Оно должно зависеть от размера данных и количества возможных повреждений или 640бит хватит всем?

Вы правы, но чексуммы позволяют отсеять часть случаев.

Зачем накладные расходы (проблемы и ошибки) от чексумм, если это уже дает рейд?

Затем что ошибки с чексуммами ещё один повод усомниться или не усомниться в правильности блока.

Или усомниться в правильности чексуммы. Кажись проблем стало больше, разве нет?

В Btrfs и в ZFS есть встроенный райд

В btrfs он есть только теоретически.

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

Про дерево хэшей слышал?

640бит хватит всем?

Пока хватает 256 за глаза. Когда найдешь два разных блока одинакового размера с одинаковым SHA256, можешь, как написано в исподниках ZFS, засылать статью в Nature.

В btrfs он есть только теоретически.

Зеркало - это тоже RAID, так что и практически то же. Если ты про RAID5/6 - то вырисовывайся точнее.

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

А зачем несколько нужных? Пусть повредился один бит в области данных копии-1 и один бит чексама копии-2.

Теперь ни копии, ни чексамы не совпадают. И не совпадают данные с соответствующими им чексамами.

можешь, как написано в исподниках ZFS, засылать статью в Nature.

Разработчики ZFS гарантируют публикацию?

Зеркало это игрушки.

Конечно же я про RAID6/RAID7.3 (последнего даже теоретически нет?)

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

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

Восстанавливают данные из бэкапа.

Дерево хешей - это когда оно повреждено, то доставай бекап?

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

Заметь я ничего не говорю про то, то что данные повреждены или нет.

Как ты в древовидной структуре найдешь данные, если у тебя внутренние узлы дерева повреждены.

А практически все файловые системы - это древовидные структуры блоков на диске.

Добавил к проблеме данных еще проблему метаданных. Прогресс!

Конечно прогресс. Контрольная сумма блока хранится отдельно от него в родителе. А корень дерева он один, его можно и десяток-другой копий хранить. С точки зрения родителя дочерний блок - это данные, контрольная сумма которых известна. Так что все упрощается.

Дерево хешей - это когда оно повреждено, то доставай бекап?

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

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

Как ты в древовидной структуре найдешь данные, если у тебя внутренние узлы дерева повреждены.

Да еще дерево надо вырастить (и сына посадить). Оккама перевернулся в гробу.

А практически все файловые системы - это древовидные структуры блоков на диске.

Дерево дереву рознь. И не надо тащить проблемы фс.

Конечно прогресс. Контрольная сумма блока хранится отдельно от него в родителе. А корень дерева он один, его можно и десяток-другой копий хранить. С точки зрения родителя дочерний блок - это данные, контрольная сумма которых известна. Так что все упрощается.

Вместо регулярной структуры придумал дерево. С точками отказа. Нет родителя (поврежден) - нет дочерей. Всегда нужен царь, желательно завести двойников, а то вдруг что. Хрен с ним что цари разные и живут разных местах. Мы то знаем как их атомарно синхронизировать, современная пластическая хирургия. Прогресс.
В общем, дальнейшее развитие темы не имеет смысла. Успехов в клонировании биткойнов

Вместо регулярной структуры придумал дерево.

Но дерево это регулярная структура. http://strictlypositive.org/diff.pdf

Какой толстенький!

А зачем несколько нужных?

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

Пусть повредился один бит в области данных копии-1 и один бит чексама копии-2.
Теперь ни копии, ни чексамы не совпадают. И не совпадают данные с соответствующими им чексамами.

И... что? Чексумма восстановится из копии-1, данные восстановятся из копии-2.

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

Чтобы узнать, какой из несовпадающих блоков правильный (или ни один).

Да еще дерево надо вырастить (и сына посадить). Оккама перевернулся в гробу.

Дерево дереву рознь. И не надо тащить проблемы фс.

Вместо регулярной структуры придумал дерево. С точками отказа. Нет родителя (поврежден) - нет дочерей. Всегда нужен царь, желательно завести двойников, а то вдруг что. Хрен с ним что цари разные и живут разных местах. Мы то знаем как их атомарно синхронизировать, современная пластическая хирургия. Прогресс.

Кончай разводить демагогию.

В Btrfs и в ZFS есть встроенный райд

В btrfs он есть только теоретически.

$ sudo btrfs fi df /mnt/data
Data, RAID5: total=4.65TiB, used=4.38TiB
System, RAID1: total=64.00MiB, used=368.00KiB
Metadata, RAID1: total=6.00GiB, used=4.92GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

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

Чтобы узнать, какой из несовпадающих блоков правильный (или ни один).

«Правильный». У меня есть подозрения, что свидетель чексуммы придумал суперкомпрессор.
А гарантированно определить порчу единичного блока (в страйпе) и исправить может рейд6.
И вообще опредление порчи одного бита в блоке решется одним битом контроля четности. И то что ты заикнулся, что сложные хеши с таким битом отлично справляются - это даже не смешно.

И сколько лет в продакшене?

И сколько лет в продакшене?

При чём тут продакшн? Тут кружок гордых btrfs-юзеров :)

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

Транзакциями защищаются только метаданные, поэтому возможна ситуация, когда данные — новые, а размер файла — старый. Поэтому для сохранения данных и рекомендуют делать rename из временного файла.

что они такое делают, что приводит к крешу

неожиданное отключение электричества? повреждение диска?

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

могут быть даже ещё более

Кажется, ты пытался привести пример

Не, я другой ананас.

И... что? Чексумма восстановится из копии-1, данные восстановятся из копии-2.

Теоретически так можно. А так где-то реализовано?

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

Это именно то, о чем я спрашивал. Если прямо так вот на ровном месте, в idle, грубо говоря, то это, конечно, удивительно.

Теоретически так можно. А так где-то реализовано?

Эм... Во всех обсуждаемых ФС?

Но это же слегка противоречит дизайну copy-on-write ФС. Ты уверен, что в zfs и btrfs такое имеет место?

А, ну да, там же нет журнала.

В принципе, можно отключить CoW для данных, и словить что-то подобное. Но такое вряд ли кто-то будет делать.

А, ну да, там же нет журнала.

В ZFS - есть.

В принципе, можно отключить CoW для данных, и словить что-то подобное. Но такое вряд ли кто-то будет делать.

а в бтрфс такое преподносится как фича.

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

Щито? Хоть смайлик поставил, чтобы все знали что шут пред нами.

Чтобы восстановить, нужна избыточность превышающая то, что испорчено.

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

Контрольная сумма не решает задачу восстановления она решает задачу отсеивания невалидной реплики.

А гарантированно определить порчу единичного блока (в страйпе) и исправить может рейд6.

Я тут подумал (и мы решили), что рейд6 нихрена не может. А вот рейд2 может, а это ТРИ дополнительных бита, чтобы определить и восстановить ОДИН, некий аналог ECC. А вы продолжате верить в свои 640 бит чексуммы хватит всем.