Ещё на opennet’е опубликовано, можно оттуда скопипастить.

Скопипащу из толксов.

Мне нечего сказать по поводу претензий к B-деревьям, т. к. я не занимаюсь computer science в узком смысле этого слова. Но

В случае провала проверки контрольной суммы какого-либо блока Reiser4 немедленно считывает соответствующий блок с девайса-реплики. Заметьте, что ZFS и Btrfs так не могут: не позволяет дизайн. Там вы должны запустить специальный фоновый сканирующий процесс под названием «скраб» и ждать, когда он доберётся до проблемного блока. Такие мероприятия программисты образно называют «костылями».

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

И, наконец, появились гетерогенные логические тома, предлагающие всё то, чего ZFS, Btrfs, block layer, а также связки FS+LVM в принципе дать не могут - это <…> прозрачная миграцией данных между подтомами

Тоже неправда (выделение моё).

Так что признанный спец допускает очевидно и заведомо неверные утверждения. Его «спецовость» не мне судить, но в достоверности всех остальных утверждений я бы на этом месте тоже усомнился.

А ты можешь чем-то подкрепить эти

Данное утверждение немного абсолютно неверно

Тоже неправда

?

1. Прозрачное исправление ошибок чексумм — это одна из главных фич что Btrfs, что ZFS. Проверяется вручную созданием ФС в режиме RAID1 и внесением искусственных повреждений в одну из копий.

2. Btrfs умеет менять профиль RAID на живой ФС (в т. ч. с изменением степени избыточности). Это напрямую противоречит словам Шишкина.

Если вы собираетесь регулярно делать пункт 2. на серьезной системе, то лучше озаботиться своевременным улаживанием дел и написанием завещания. Ибо чревато.

Твое утверждение

Проверяется вручную

Его утверждение

Там вы должны запустить специальный фоновый сканирующий процесс под названием «скраб» и ждать, когда он доберётся до проблемного блока.

?

По второму утверждению ты опровергаешь вообще что-то свое.

Выводы, думаю, понятны.

Если вы собираетесь регулярно делать пункт 2. на серьезной системе, то лучше озаботиться своевременным улаживанием дел и написанием завещания. Ибо чревато.

Вот смотри, я своим словам какие-то обоснования привожу, а ты нет, просто голословно что-то кричишь. Дальше продолжать?

Твое утверждение

Проверяется вручную

«Проверяется вручную» моё утверждение. Если создать экземпляр btrfs из двух зеркал и вручную повредить одно из них в занятом месте, а потом произвести чтение всех данных с ФС, то можно увидеть, что ФС прозрачно исправляет все встреченные повреждения, т. о. Шишкин не прав.

По второму утверждению ты опровергаешь вообще что-то свое.

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

Btrfs умеет менять профиль RAID на живой ФС (в т. ч. с изменением степени избыточности), при этом в случае прерванной миграции ФС продолжает работать штатно. В строгом смысле гетерогенное хранение данных не является фичой btrfs (поскольку не существует явной возможности приказать ФС хранить одни файлы с одним профилем, а другие с другим), но сама возможность привести ФС в такое состояние, в котором разные файлы будут храниться с разной избыточностью и это будет продолжать штатно работать, противоречит словам Шишкина на тему «принципиальной невозможности».

Если создать экземпляр btrfs из двух зеркал и вручную повредить одно из них в занятом месте, а потом произвести чтение всех данных с ФС, то можно увидеть, что Шишкин не прав.

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

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

а чтобы проверить слова шишкина нужно не все данные прочитать, а поврежденные

Можно и так. Все данные читать необязательно, если ты знаешь, какие именно блоки ты повредил.

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

Если ты хочешь конструктивно покритиковать мнение специалиста с мировым именем, сказать

Очень сложно спорить с оппонентом (в данном случае с Шишкиным), который придумывает термины на ходу. Но если чуть-чуть вдуматься, то я опровергаю в точности то, о чём он говорит.

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

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

Что значит «скраб может быть частью реализации btrfs»? Конечно, скраб будет частью реализации btrfs! А чего ещё, драйвера клавиатуры, что ли?

Попробуй выражаться более внятно.

сказать <…> явно не достаточно.

У тебя избирательная слепота? Я там дальше целый абзац написал с подробным объяснением того, где именно Шишкин нагнал.

так речь и идет о том что внутри происходит шишкин утверждает что reiser умеет это делать принципиально быстрее.

А давай не придумывать отсебятину? Речь идёт о конкретном высказывании Шишкина. Вот оно:

В случае провала проверки контрольной суммы какого-либо блока Reiser4 немедленно считывает соответствующий блок с девайса-реплики. Заметьте, что ZFS и Btrfs так не могут: не позволяет дизайн. Там вы должны запустить специальный фоновый сканирующий процесс под названием «скраб» и ждать, когда он доберётся до проблемного блока. Такие мероприятия программисты образно называют «костылями».

Это утверждение — ложно. Обоснование — выше. Ещё вопросы?

Я правильно понимаю, что на любом сайте через JavaScript можно сделать скрипт в цикле сохраняющий файл о котором говорит Шишкин в какой-нибудь localstorage и быстро его удаляющий и у пользователей Btrfs закончится свободное место на диске?

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

1. Сообщить что что то можно, как и сообщить что чего то сделать нельзя - не обоснование (не доказательство). Это высказывание, которое, как известно, может быть и ложным.

2. Мне, честно говоря, безразлично - делайте на здоровье. В конце концов ваши проблемы - ваши проблемы.

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

и одно другому не противоречит. можно делать всё прозрачно при помощи костыля

А вы уверены что вы хотите видеть этот proof of concept в свободном доступе?

через JavaScript можно сделать скрипт в цикле сохраняющий файл о котором говорит Шишкин в какой-нибудь localstorage и быстро его удаляющий

Там он еще говорил о записи по смещению, но localstorage ЕМНИП не имеет такого апи.

я не согласен с этим обоснованием

Проблема на твоей стороне.

шишкин говорит что внутри костыль. ты говоришь что btrfs делает всё прозрачно. и одно другому не противоречит. можно делать всё прозрачно при помощи костыля

«Одно из самых неблагодарных занятий — объяснять упрямому неспециалисту, в чём именно состоит проблема в том некорректном упрощении, которое пустило корни в его голове»

Не просто «внутри костыль», а конкретный костыль, при этом также утверждается, что без костыля принципиально нельзя. Это всё можно проверить в явном виде руками — создать ФС, повредить данные, попытаться их прочесть, не запуская скраб.

нужно знать что конкретно делает btrfs

Я знаю, что конкретно делает btrfs (читал код). Ты тоже можешь прочитать код.

конкретный костыль - скраб, который является деталью реализации btrfs как ты собрался проверять руками что делает btrfs внутри?

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

Я знаю, что конкретно делает btrfs (читал код).

ну это уже лучше. а что конкретно он делает?

Сообщить что что то можно, как и сообщить что чего то сделать нельзя - не обоснование (не доказательство)

Привести конкретный (фальсифицируемый) эксперимент, подробно его описав — это, на мой взгляд, достаточный уровень доказательства для беседы в комментах на ЛОРе. Иными словами, лично к вам домой с демонстрацией я не поеду.

Мне, честно говоря, безразлично

Ну то есть заявление было голословным и возразить по теме нечего. Хорошо.

Привести конкретный (фальсифицируемый) эксперимент, подробно его описав

успех этого эксперимента не противоречит словам шишкина.

То есть ты хочешь сказать, что btrfs, когда ей попадается повреждённая реплика, автоматически запускает внутри себя скраб, ждёт его результатов, после чего повторяет чтение? Это, конечно, настолько идиотское предположение, что мне даже в голову не пришло интерпретировать твои слова в эту сторону.

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

Обоснуй.

а что конкретно он делает?

То, что со слов Шишкина сделать невозможно.

То, что со слов Шишкина сделать невозможно.

Со слов Шишкина это невозможно сделать немедленно

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

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

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

Вот ты как спец по btrfs что можешь сказать по поводу теста Шишкина с засиранием всей ФС(без снапшотов и сабвольюмов) методом создания/удаления кучи файлов? Если это работает - это же капец!

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

Начнём с того, что я не спец по btrfs...

Нет, в общем случае это не работает, я могу создавать и удалять файлы до второго пришествия и ФС ровным счётом ничего не будет. Без proof of concept говорить не о чем.

localstorage

Это обычная строка (а точнее массив строк), он говорит про файлы.

Ещё раз, для особо понятливых:

<…> В случае провала проверки контрольной суммы какого-либо блока Reiser4 немедленно считывает соответствующий блок с девайса-реплики. Заметьте, что ZFS и Btrfs так не могут: не позволяет дизайн. Там вы должны запустить специальный фоновый сканирующий процесс под названием «скраб» и ждать, когда он доберётся до проблемного блока. <…>

Wrong.

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

Если потеря ноды является проблемой, то это говно, а не серьёзная система.

Годное интервью. Хорошо Шишкин приложил хипстеров и смузихлебов - разработчиков btrfs и прочего новомодного шлака.

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

ZFS и Btrfs при обнаружении повреждения немедленно считывают с диска валидную копию (точнее, следующую копию). Чтобы это произошло, я как пользователь ничего запускать не должен.

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

btrfs, когда ей попадается повреждённая реплика, автоматически запускает внутри себя скраб, ждёт его результатов, после чего повторяет чтение?

Во первых, скраб здесь скорее всего это не то же самое что команда btrfs scrub. Во вторых, ты видел, сколько kernel worker’ов запускает btrfs? Скраб в данном контексте это один из этих worker’ов. Я не буду ничего утверждать, но на мой взгляд утверждение Шишкина в таком контексте выглядит правдоподобно.

Насчет btrfs я не в курсе, а в ZFS с Ceph есть явные scrub-процедуры. Причем в Ceph с уровнем реплики 2(когда хранится ОДНА дополнительная копия) точно починить блоки ТОЛЬКО указав какой из них валидный(при уровне реплики 3 и более проблема обычно не стоит - где одинаковые копии, там и целый блок - остальные перезатираются)

Во первых, скраб здесь скорее всего это не то же самое что команда btrfs scrub.

А что тогда? Давай не заниматься отсебятиной.

Во вторых, ты видел, столько kernel worker’ов запускает btrfs? Скраб в данном контексте это один из этих worker’ов.

Откуда взялось выделенное утверждение?

но на мой взгляд утверждение Шишкина в таком контексте выглядит правдоподобно.

А на мой взгляд, то, чем ты занимаешься, выглядит как натягивание совы на глобус.

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

шишкин не говорит, что пользователь что-то должен запускать. он только говорит что это можно сделать только при помощи менее эффективного костыля.

Шишкин отрастил шишку и водит ею по линукс сообществу.

Линус Торвальдс в недавнем интервью так гордился VFS и её скоростью работы, а Эдуард опустил

Откуда взялось выделенное утверждение?

Моя догадка, не более того.

шишкин не говорит, что пользователь что-то должен запускать.

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

В случае провала проверки контрольной суммы какого-либо блока Reiser4 немедленно считывает соответствующий блок с девайса-реплики. Заметьте, что ZFS и Btrfs так не могут: не позволяет дизайн. Там вы должны запустить специальный фоновый сканирующий процесс под названием «скраб» и ждать, когда он доберётся до проблемного блока. Такие мероприятия программисты образно называют «костылями».

интересный community service

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

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