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

Я это называю «еда».

Сразу видно, что математик. Никто ничего не умеет, никто ничего не понимает, нужно тридцать лет исследований и тогда-то мы напишем ПРЕКРАСНУЮ ФС БУДУЩЕГО. Правда работать с другими людьми Шишкин не умеет, поэтому его код никуда не возьмут.

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

А по-моему

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

99% людей, не знающих о споре в этом треде, воспримут это предложение как запуск btrfs scrub. Вы должны запустить фоновый сканирующий процесс под названием скраб и ждать когда он доберется до проблемного блока. Ну все про btrfs scrub. Господин Шишкин давая интервью должен был позаботиться, чтобы его слова интерпретировали правильно. Да о чем это я, он просто набросил, и в прошлом интервью он делал то же самое)

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

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

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

Нет CVE? Нет проблемы!

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

Хоть на второй странице отмечусь.

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

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

«Запустить и ждать» это и есть «не могут немедленно». А «не могут в принципе» это ваши фантазии.

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

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

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

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

Всё равно высказывание Шишкина остаётся неправдой. Могут, немедленно, запускать ничего не нужно, ждать тоже не нужно (восстановление происходит за O(1)). Ещё вопросы?

Без proof of concept говорить не о чем.

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

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

Да-да, это тоже. Я работал с такими чуваками. Несмотря на хорошие идеи, чаще всего выгнать такого паренька ссаными тряпками – хорошее решение для продуктивности команды. Да, будет больше trial and error, до каких-то вещей команда доедет позже, но по крайней мере, она будет ехать, а не застрянет в бесконечном аду пассивной агрессии.

то, что её нет в RHEL - это таки мощный аргумент за то, что с ней что-то сильно не все в порядке и красношляпы об этом прекрасно знают

Это значит лишь то, что в RHEL на зарплате нет квалифицированных разработчиков btrfs, а имеющиеся разработчики не справляются с бэкпортированием фиксов из апстрима в свой копролит.

Уже давно обсудили, даже какой-то инсайд раскопали по этому поводу в своё время.

а в ZFS с Ceph есть явные scrub-процедуры

И что с того? Когда пользователь пытается прочитать битый блок ему автоматом подсунут целый блок из копии или блок восстановится из чётности, самому делать ведь ничего не надо.

Не надо обобщать на всех математиков. Это просто неудачный экземпляр.

(восстановление происходит за O(1)). Ещё вопросы? собственно в этом и есть главный вопрос. шишкин говорит что не может такого быть. может врёт, но если бы был описан принцип, как это происходит за O(1) то тогда бы стало точно понятно

Когда пользователь пытается прочитать битый блок ему автоматом подсунут целый блок из копии или блок восстановится из чётности

Для ceph верно только при использовании Bluestore. Для устаревшего Filestore - неверно, контрольные суммы сверялись только при ручном или периодическом deepscrub’е.

Не надо обобщать на всех математиков. Это просто неудачный экземпляр.

Удачных я встречал только в RND.

удачные математики редко идут в программисты

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

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

ммм, насчет ceph я ведь явно сказал что при уровне реплики 2 это НЕ работает(пользователю ОТДАЕТСЯ то битый блок, то нормальный, я проверял). Но к Ceph у меня претензий нет, там явно сказано что рекомендуемый уровень реплики - 3 и более, там таких проблем нет.

но ведь насрать как там в цеф, тут какбэ про zfs и btrfs.

осталось понять, при чём здесь цеф

Учитывая амбиции Шишкина в плане экспансии reiser4 как сетевой ФС(да, это план на отдаленное будущее у него, но всё же), мне кажется это релевантным

Это значит лишь то, что в RHEL на зарплате нет квалифицированных разработчиков btrfs, а имеющиеся разработчики не справляются с бэкпортированием фиксов из апстрима в свой копролит.

Последняя версия как бы уже и не очень копролит в смысле фич ядра, но а где тогда есть разработчики?! Значит одной рукой её продвигать как вообще дефолтную ФС, а другой «не справляются». Хотя разработка уже больше 10 лет

удачные математики редко идут в программисты

О чем и речь.

а где тогда есть разработчики?

В оракле, фейсбуке, сусе, вроде ничего не забыл.

Значит одной рукой её продвигать как вообще дефолтную ФС, а другой «не справляются»

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

Но ZFS-подобные ФС (также как и любые ФС в связках с LVM) работают только с виртуальными дисковыми устройствами (выделяют виртуальные дисковые адреса из числа свободных, дефрагментируют эти виртуальные устройства и т.д.). А что происходит на реальных устройствах они даже понятия не имеют!

а этот шишкин знатный пизд%бол, судя по этому и другим «сильным» заявлениям, либо таки невежда

Всё равно …

Ну всё равно так всё равно. Я вам просто указал, что вы опровергаете не слова Шишкина, а какие-то свои фантазии по мотивам.

восстановление происходит за O(1)

Измеряли или тоже «всё равно»?

Ещё вопросы?

Нет

Ну и какие же у меня «фантазии по мотивам»?

Измеряли или тоже «всё равно»?

Читал код.

Ну и какие же у меня «фантазии по мотивам»?

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

Сомнения пока есть в вашей способности понимать текст на русском.

Читал код.

Код вообще или код btrfs? И вы вот так «с листа» глянув код файловой системы можете «на глаз» оценивать асимптоматику? Завидую таким недюжинным способностям.

ч

вы зачем-то проигнорировали слова про «немедленно»

ты дебил? сколько раз повторять, что у btrfs и zfs блок восстанавливается при первой попутке его прочитать. «немедленно»!!!!1111

Могут, немедленно, запускать ничего не нужно, ждать тоже не нужно (восстановление происходит за O(1)). Ещё вопросы?

Где выдают столько запятых?

я не занимаюсь computer science в узком смысле этого слова

То есть CS - это «узкий смысл», а твоё ковыряние отвёрткой в wifi-роутере - это «широкий смысл» профессии. Лол.

Дааа, бтрфс не жилец ...

сколько раз повторять, что у btrfs и zfs блок восстанавливается при первой попутке его прочитать. «немедленно»

Ну а я про что - опять жопой завертел.

Это кто писал?

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

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

Есть у меня один хороший дилер, обращайся, если что. Отдам за недорого.

intelfx, а как ты вот это его утверждение прокомментируешь?:

Не избавилась. Всё то, о чём я упоминал 11 лет назад, актуально и поныне. Одна из проблем Btrfs, делающая последнюю непригодной для серьёзных нужд, - это проблема свободного места. Я уж не говорю о том, что пользователю предлагается бежать в магазин за новым диском в ситуациях, когда любая другая ФС показала бы ещё уйму свободного места на разделе. Невозможность завершить операцию над логическим томом по причине нехватки свободного места - это тоже не самое страшное. Хуже всего то, что непривилегированный пользователь почти всегда может за достаточно короткое время в обход любых дисковых квот лишить всех свободного места. Выглядит это так (проверено для ядра Linux 5.12). На свежеинсталлированной системе запускается скрипт, который в цикле создаёт в домашней директории файлы с определенными именами, записывает в них данные по определенным смещениям и затем удаляет эти файлы. Через минуту работы этого скрипта ничего необычного не происходит. Через пять минут порция занятого места на разделе слегка увеличивается. Через два-три часа она достигает 50% (при начальном значении 15%). А после пяти-шести часов работы скрипт валится с ошибкой «нет свободного места на разделе». После этого вы уже не в состоянии записать на ваш раздел даже 4К файл. Происходит интересная ситуация: вы ничего на раздел в итоге не записали, а всё свободное место (порядка 85%) куда-то улетучилось. Анализ раздела, подвергнутого такой атаке, покажет множество узлов дерева, содержащих всего один айтем (объект, снабженный ключом), размером несколько байт. То есть, контент, который ранее занимал 15% дискового пространства оказался равномерно «размазанным» на весь раздел так, что новый файл записать уже некуда, ибо его ключ больше всех существующих, а свободные блоки на разделе закончились. Причем это всё происходит уже на базовой конфигурации Btrfs (безо всяких снапшотов, сабвольюмов и пр.), и не имеет значения то, как вы решили хранить тела файлов в той ФС (как «фрагменты» в дереве, или же как экстенты неформатированных блоков) - конечный результат будет один и тот же.

Ты сначала топил за «невозможно», а когда тебя натыкали, что читать не умеешь, начал переобуваться

А с чего ты взял, что это один и тот же человек?

Шишкин прав – Бртфс не имеет права на жизнь, лучше ЗФС допилить.

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

классика оверинжиниринга и блоатвари. нах это говно, простой журналируемой фс достаточно

Настолько не наблюдается, что в базе знаний SuSE целая страница есть по этому поводу:

https://www.suse.com/support/kb/doc/?id=000018021

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

Сомнения пока есть в вашей способности понимать текст на русском.

Может быть, в вашей?

И вы вот так «с листа» глянув код файловой системы можете «на глаз» оценивать асимптоматику? Завидую

Да, асимптотику цикла с константным количеством итераций я могу оценить на глаз. Завидуйте.

А при чём тут вообще space cache?

Михаэль Шигорин не годует

Царь! Залогинься!

Ну надо признать что у «самого фейсбука» достаточно специфичные use-case, не похожие ни на типичные сценарии типичного десктопа, ни даже более менее классического сервера. Так что фейсбук конечно развивает и btrfs, и systemd, но он может себе позволить и на rawhide-ветке сидеть.

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