Мне нечего сказать по поводу претензий к B-деревьям, т. к. я не занимаюсь computer science в узком смысле этого слова. Но
В случае провала проверки контрольной суммы какого-либо блока Reiser4 немедленно считывает соответствующий блок с девайса-реплики. Заметьте, что ZFS и Btrfs так не могут: не позволяет дизайн. Там вы должны запустить специальный фоновый сканирующий процесс под названием «скраб» и ждать, когда он доберётся до проблемного блока. Такие мероприятия программисты образно называют «костылями».
Данное утверждение немного абсолютно неверно, что сигнализирует о некой предвзятости (потому что в некомпетентности этого человека обвинить язык не поворачивается).
И, наконец, появились гетерогенные логические тома, предлагающие всё то, чего ZFS, Btrfs, block layer, а также связки FS+LVM в принципе дать не могут - это <…> прозрачная миграцией данных между подтомами
Тоже неправда (выделение моё).
Так что признанный спец допускает очевидно и заведомо неверные утверждения. Его «спецовость» не мне судить, но в достоверности всех остальных утверждений я бы на этом месте тоже усомнился.
Прозрачное исправление ошибок чексумм — это одна из главных фич что Btrfs, что ZFS. Проверяется вручную созданием ФС в режиме RAID1 и внесением искусственных повреждений в одну из копий.
Btrfs умеет менять профиль RAID на живой ФС (в т. ч. с изменением степени избыточности). Это напрямую противоречит словам Шишкина.
Если вы собираетесь регулярно делать пункт 2. на серьезной системе, то лучше озаботиться своевременным улаживанием дел и написанием завещания. Ибо чревато.
Если вы собираетесь регулярно делать пункт 2. на серьезной системе, то лучше озаботиться своевременным улаживанием дел и написанием завещания. Ибо чревато.
Вот смотри, я своим словам какие-то обоснования привожу, а ты нет, просто голословно что-то кричишь. Дальше продолжать?
«Проверяется вручную» моё утверждение. Если создать экземпляр btrfs из двух зеркал и вручную повредить одно из них в занятом месте, а потом произвести чтение всех данных с ФС, то можно увидеть, что ФС прозрачно исправляет все встреченные повреждения, т. о. Шишкин не прав.
По второму утверждению ты опровергаешь вообще что-то свое.
Очень сложно спорить с оппонентом (в данном случае с Шишкиным), который изобретает термины (такие, как «гетерогенные логические тома»,«прозрачная миграция данных между подтомами») на ходу. Но если чуть-чуть вдуматься, то я опровергаю в точности то, о чём он говорит.
Btrfs умеет менять профиль RAID на живой ФС (в т. ч. с изменением степени избыточности), при этом в случае прерванной миграции ФС продолжает работать штатно. В строгом смысле гетерогенное хранение данных не является фичой btrfs (поскольку не существует явной возможности приказать ФС хранить одни файлы с одним профилем, а другие с другим), но сама возможность привести ФС в такое состояние, в котором разные файлы будут храниться с разной избыточностью и это будет продолжать штатно работать, противоречит словам Шишкина на тему «принципиальной невозможности».
Если создать экземпляр btrfs из двух зеркал и вручную повредить одно из них в занятом месте, а потом произвести чтение всех данных с ФС, то можно увидеть, что Шишкин не прав.
утверждения что исправление делается прозрачно, и то что для этого нужен процесс-скраб не противоречат друг другу. а чтобы проверить слова шишкина нужно не все данные прочитать, а поврежденные, и посмотреть какая система будет быстрее в среднем. и то, это косвенное свидетельство, скраб тоже можно стараться сделать умным.
Ты начинаешь нести чушь и путаться на ходу в показаниях. Нет, либо исправление делается прозрачно, либо для него нужен отдельный явный процесс (скраб). Третьего не дано.
а чтобы проверить слова шишкина нужно не все данные прочитать, а поврежденные
Можно и так. Все данные читать необязательно, если ты знаешь, какие именно блоки ты повредил.
Дальше слова про производительность и т. п. вообще не в тему.
Если ты хочешь конструктивно покритиковать мнение специалиста с мировым именем, сказать
Очень сложно спорить с оппонентом (в данном случае с Шишкиным), который придумывает термины на ходу. Но если чуть-чуть вдуматься, то я опровергаю в точности то, о чём он говорит.
явно не достаточно. Я бы с удовольствием выслушал мнение, если оно не просто чтобы поспорить, когда тебе что-то полюбилось и тебе не нравится, что это раскритиковали. Я сам интересуюсь btrfs в прикладных целях. Такие интервью бьют по уровню доверия к btrfs.
да дано это третье, скраб может быть частью реализации btrfs. и разница тогда будет именно в скорости, потому что одна реализация сразу знает куда смотреть, а другая сканит данные на предмет что сломалось.
А давай не придумывать отсебятину? Речь идёт о конкретном высказывании Шишкина. Вот оно:
В случае провала проверки контрольной суммы какого-либо блока Reiser4 немедленно считывает соответствующий блок с девайса-реплики. Заметьте, что ZFS и Btrfs так не могут: не позволяет дизайн. Там вы должны запустить специальный фоновый сканирующий процесс под названием «скраб» и ждать, когда он доберётся до проблемного блока. Такие мероприятия программисты образно называют «костылями».
Это утверждение — ложно. Обоснование — выше. Ещё вопросы?
Я правильно понимаю, что на любом сайте через JavaScript можно сделать скрипт в цикле сохраняющий файл о котором говорит Шишкин в какой-нибудь localstorage и быстро его удаляющий и у пользователей Btrfs закончится свободное место на диске?
Нет, потому что никакого proof of concept Шишкиным продемонстрировано не было, а в реальности что-то ничего похожего не наблюдается, даже если создавать и удалять файлы целую вечность.
Сообщить что что то можно, как и сообщить что чего то сделать нельзя - не обоснование (не доказательство). Это высказывание, которое, как известно, может быть и ложным.
Мне, честно говоря, безразлично - делайте на здоровье. В конце концов ваши проблемы - ваши проблемы.
я не согласен с этим обоснованием. нужно знать что конкретно делает btrfs, шишкин говорит что внутри костыль. ты говоришь что btrfs делает всё прозрачно.
и одно другому не противоречит. можно делать всё прозрачно при помощи костыля
шишкин говорит что внутри костыль. ты говоришь что btrfs делает всё прозрачно. и одно другому не противоречит. можно делать всё прозрачно при помощи костыля
«Одно из самых неблагодарных занятий — объяснять упрямому неспециалисту, в чём именно состоит проблема в том некорректном упрощении, которое пустило корни в его голове»
Не просто «внутри костыль», а конкретный костыль, при этом также утверждается, что без костыля принципиально нельзя. Это всё можно проверить в явном виде руками — создать ФС, повредить данные, попытаться их прочесть, не запуская скраб.
нужно знать что конкретно делает btrfs
Я знаю, что конкретно делает btrfs (читал код). Ты тоже можешь прочитать код.
Сообщить что что то можно, как и сообщить что чего то сделать нельзя - не обоснование (не доказательство)
Привести конкретный (фальсифицируемый) эксперимент, подробно его описав — это, на мой взгляд, достаточный уровень доказательства для беседы в комментах на ЛОРе. Иными словами, лично к вам домой с демонстрацией я не поеду.
Мне, честно говоря, безразлично
Ну то есть заявление было голословным и возразить по теме нечего. Хорошо.
То есть ты хочешь сказать, что btrfs, когда ей попадается повреждённая реплика, автоматически запускает внутри себя скраб, ждёт его результатов, после чего повторяет чтение? Это, конечно, настолько идиотское предположение, что мне даже в голову не пришло интерпретировать твои слова в эту сторону.
Но можно пронаблюдать, за сколько времени произойдёт чтение повреждённых данных, и сравнить его с длительностью скраба на этой ФС.
Но можно пронаблюдать, за сколько времени произойдёт чтение повреждённых данных, и сравнить его с длительностью скраба на этой ФС.
я про то и говорил, что эксперимент нужен сложнее и нужно измерять среднюю скорость.
ну и я бы ожидал что скраб запускается не когда возникла нужда, а работает всегда, если в нём есть необходимость, и это тоже должно быть возможно засечь.
Вот ты как спец по btrfs что можешь сказать по поводу теста Шишкина с засиранием всей ФС(без снапшотов и сабвольюмов) методом создания/удаления кучи файлов? Если это работает - это же капец!
Нет, в общем случае это не работает, я могу создавать и удалять файлы до второго пришествия и ФС ровным счётом ничего не будет. Без proof of concept говорить не о чем.
<…> В случае провала проверки контрольной суммы какого-либо блока Reiser4 немедленно считывает соответствующий блок с девайса-реплики. Заметьте, что ZFS и Btrfs так не могут: не позволяет дизайн. Там вы должны запустить специальный фоновый сканирующий процесс под названием «скраб» и ждать, когда он доберётся до проблемного блока. <…>
без описания принципа, как это делает btrfs, хотя бы в общих чертах не верю. то что сказал шишкин можно интерпретировать весьма широко и wrong только достаточно узкая интерпретация.
ZFS и Btrfs при обнаружении повреждения немедленно считывают с диска валидную копию (точнее, следующую копию). Чтобы это произошло, я как пользователь ничего запускать не должен.
Оба утверждения проверяются прямым экспериментом или чтением кода (который, уж извини, я вслух зачитывать не буду). Всё.
btrfs, когда ей попадается повреждённая реплика, автоматически запускает внутри себя скраб, ждёт его результатов, после чего повторяет чтение?
Во первых, скраб здесь скорее всего это не то же самое что команда btrfs scrub. Во вторых, ты видел, сколько kernel worker’ов запускает btrfs? Скраб в данном контексте это один из этих worker’ов. Я не буду ничего утверждать, но на мой взгляд утверждение Шишкина в таком контексте выглядит правдоподобно.
Насчет btrfs я не в курсе, а в ZFS с Ceph есть явные scrub-процедуры. Причем в Ceph с уровнем реплики 2(когда хранится ОДНА дополнительная копия) точно починить блоки ТОЛЬКО указав какой из них валидный(при уровне реплики 3 и более проблема обычно не стоит - где одинаковые копии, там и целый блок - остальные перезатираются)
шишкин не говорит, что пользователь что-то должен запускать.
Я буду продолжать тыкать тебя носом в цитату из интервью, пока ты не успокоишься и не прекратишь ходить по кругу.
В случае провала проверки контрольной суммы какого-либо блока Reiser4 немедленно считывает соответствующий блок с девайса-реплики. Заметьте, что ZFS и Btrfs так не могут: не позволяет дизайн. Там вы должны запустить специальный фоновый сканирующий процесс под названием «скраб» и ждать, когда он доберётся до проблемного блока. Такие мероприятия программисты образно называют «костылями».