LINUX.ORG.RU

Интервью с разработчиком Reiser4 Эдуардом Шишкиным

 , ,


0

4

На habr.com опубликовано новое интервью с разработчиком Reiser4 Эдуардом Шишкиным в формате вопрос-ответ.

>>> Ссылка на интервью

★★★★★

Проверено: Shaman007 ()
Последнее исправление: Pinkbyte (всего исправлений: 3)

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

Harliff ★★★★★
()

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


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

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

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

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

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

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

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

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

?

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

anonymous
()
Ответ на: комментарий от intelfx

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

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

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

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

?

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

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

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

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 4)
Ответ на: комментарий от intelfx

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 4)
Ответ на: комментарий от intelfx

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

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

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

anonymous
()
Ответ на: комментарий от intelfx

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

intelfx ★★★★★
()

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

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 2)
Ответ на: комментарий от EXL

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

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

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

anonymous
()
Ответ на: комментарий от intelfx

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

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

anonymous
()
Ответ на: комментарий от intelfx

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

anonymous
()
Ответ на: комментарий от EXL

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

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

goingUp ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

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

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

anonymous
()
Ответ на: комментарий от intelfx

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

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

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

anonymous
()
Ответ на: комментарий от intelfx

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

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от EXL

localstorage

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

fernandos ★★★
()
Последнее исправление: fernandos (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

Wrong.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

anonymous
()

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

Reset ★★★★★
()
Ответ на: комментарий от intelfx

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

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

eternal_sorrow ★★★★★
()
Последнее исправление: eternal_sorrow (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

Pinkbyte ★★★★★
()
Ответ на: комментарий от eternal_sorrow

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

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

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

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

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

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

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

anonymous
()

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

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

anonymous
()
Ответ на: комментарий от intelfx

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

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

eternal_sorrow ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.