LINUX.ORG.RU

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

 , , ,


0

4

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

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

★★★★★

Проверено: Shaman007 ()

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

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

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

А по-моему

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

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

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

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

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

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

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

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

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

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

anonymous ()

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

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

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

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

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

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

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

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

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

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

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

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: Начнём с того, что я не спец по btrfs... от intelfx

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

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

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

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

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

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

anonymous ()
Ответ на: Re: Начнём с того, что я не спец по btrfs... от anonymous

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

О чем и речь.

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

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

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

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

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

intelfx ★★★★★ ()

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

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

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

Всё равно …

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

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

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

Ещё вопросы?

Нет

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

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

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

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

Читал код.

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

ч

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

theNamelessOne ★★★★★ ()

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

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

Vsevolod-linuxoid ★★★★★ ()
Ответ на: комментарий от webhive

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

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

theNamelessOne ★★★★★ ()
Ответ на: комментарий от Vsevolod-linuxoid

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

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

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

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

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

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

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

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

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

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

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

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

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