Сразу видно, что математик. Никто ничего не умеет, никто ничего не понимает, нужно тридцать лет исследований и тогда-то мы напишем ПРЕКРАСНУЮ ФС БУДУЩЕГО. Правда работать с другими людьми Шишкин не умеет, поэтому его код никуда не возьмут.
на мой взгляд утверждение Шишкина в таком контексте выглядит правдоподобно.
А по-моему
Там вы должны запустить специальный фоновый сканирующий процесс под названием «скраб» и ждать, когда он доберётся до проблемного блока.
99% людей, не знающих о споре в этом треде, воспримут это предложение как запуск btrfs scrub. Вы должны запустить фоновыйсканирующийпроцесс под названием скраб и ждать когда он доберется до проблемного блока. Ну все про btrfs scrub. Господин Шишкин давая интервью должен был позаботиться, чтобы его слова интерпретировали правильно. Да о чем это я, он просто набросил, и в прошлом интервью он делал то же самое)
вопрос в том кто такой вы в этом предложении. пользователь, или разработчик файловой системы? я от разработчика файловой системы ожидаю, что он это говорит про другого разработчика файловой системы, который хочет сделать ту же фичу на btrfs.
это можно понять и как вы - пользователь, и тогда шишкин всё врет, легко проверить. а если вы - разработчик, то тогда фиг знает.
Вот ты как спец по btrfs что можешь сказать по поводу теста Шишкина с засиранием всей ФС(без снапшотов и сабвольюмов) методом создания/удаления кучи файлов? Если это работает - это же капец!
Шишкин кроме всего прочего фактически жалуется на то что его задрали тупые и безграмотные разработчики. Обсуждение здесь очень неплохо подтверждает правомерность его жалоб.
В случае провала проверки контрольной суммы какого-либо блока Reiser4 немедленно считывает соответствующий блок с девайса-реплики. Заметьте, что ZFS и Btrfs так не могут: <для непонятливых - в данном контексте «так» это «немедленно» см. выше.> не позволяет дизайн. Там вы должны запустить … и ждать
«Запустить и ждать» это и есть «не могут немедленно». А «не могут в принципе» это ваши фантазии.
я про то и говорил, что эксперимент нужен сложнее и нужно измерять среднюю скорость.
не нужно усложнять, достаточно хотя бы на минимальном уровне понимать работу этих фс, чего у тебя явно не наблюдается.
ну и я бы ожидал что скраб запускается не когда возникла нужда, а работает всегда, если в нём есть необходимость, и это тоже должно быть возможно засечь.
скраб - это механизм профилактической проверки целостности по расписанию. также повреждения обнаруживаются и исправляются прозрачно при каждом чтении блока благодаря чексумам.
Всё равно высказывание Шишкина остаётся неправдой. Могут, немедленно, запускать ничего не нужно, ждать тоже не нужно (восстановление происходит за O(1)). Ещё вопросы?
Я тоже не разбираюсь как btrfs устроена, но то, что её нет в RHEL - это таки мощный аргумент за то, что с ней что-то сильно не все в порядке и красношляпы об этом прекрасно знают.
Шишкин кроме всего прочего фактически жалуется на то что его задрали тупые и безграмотные разработчики. Обсуждение здесь очень неплохо подтверждает правомерность его жалоб.
Да-да, это тоже. Я работал с такими чуваками. Несмотря на хорошие идеи, чаще всего выгнать такого паренька ссаными тряпками – хорошее решение для продуктивности команды. Да, будет больше trial and error, до каких-то вещей команда доедет позже, но по крайней мере, она будет ехать, а не застрянет в бесконечном аду пассивной агрессии.
то, что её нет в RHEL - это таки мощный аргумент за то, что с ней что-то сильно не все в порядке и красношляпы об этом прекрасно знают
Это значит лишь то, что в RHEL на зарплате нет квалифицированных разработчиков btrfs, а имеющиеся разработчики не справляются с бэкпортированием фиксов из апстрима в свой копролит.
Уже давно обсудили, даже какой-то инсайд раскопали по этому поводу в своё время.
И что с того? Когда пользователь пытается прочитать битый блок ему автоматом подсунут целый блок из копии или блок восстановится из чётности, самому делать ведь ничего не надо.
(восстановление происходит за O(1)). Ещё вопросы?
собственно в этом и есть главный вопрос. шишкин говорит что не может такого быть. может врёт, но если бы был описан принцип, как это происходит за O(1) то тогда бы стало точно понятно
Когда пользователь пытается прочитать битый блок ему автоматом подсунут целый блок из копии или блок восстановится из чётности
Для ceph верно только при использовании Bluestore. Для устаревшего Filestore - неверно, контрольные суммы сверялись только при ручном или периодическом deepscrub’е.
Когда пользователь пытается прочитать битый блок ему автоматом подсунут целый блок из копии или блок восстановится из чётности, самому делать ведь ничего не надо
ммм, насчет ceph я ведь явно сказал что при уровне реплики 2 это НЕ работает(пользователю ОТДАЕТСЯ то битый блок, то нормальный, я проверял). Но к Ceph у меня претензий нет, там явно сказано что рекомендуемый уровень реплики - 3 и более, там таких проблем нет.
Это значит лишь то, что в RHEL на зарплате нет квалифицированных разработчиков btrfs, а имеющиеся разработчики не справляются с бэкпортированием фиксов из апстрима в свой копролит.
Последняя версия как бы уже и не очень копролит в смысле фич ядра, но а где тогда есть разработчики?! Значит одной рукой её продвигать как вообще дефолтную ФС, а другой «не справляются». Хотя разработка уже больше 10 лет
Но ZFS-подобные ФС (также как и любые ФС в связках с LVM) работают только с виртуальными дисковыми устройствами (выделяют виртуальные дисковые адреса из числа свободных, дефрагментируют эти виртуальные устройства и т.д.). А что происходит на реальных устройствах они даже понятия не имеют!
а этот шишкин знатный пизд%бол, судя по этому и другим «сильным» заявлениям, либо таки невежда
Я ж вам написал - вы зачем-то проигнорировали слова про «немедленно» и на основе этого нафантазировали про «невозможно», попутно усомнившись в компетенции автора.
Сомнения пока есть в вашей способности понимать текст на русском.
Читал код.
Код вообще или код btrfs? И вы вот так «с листа» глянув код файловой системы можете «на глаз» оценивать асимптоматику? Завидую таким недюжинным способностям.
intelfx, а как ты вот это его утверждение прокомментируешь?:
Не избавилась. Всё то, о чём я упоминал 11 лет назад, актуально и поныне. Одна из проблем Btrfs, делающая последнюю непригодной для серьёзных нужд, - это проблема свободного места. Я уж не говорю о том, что пользователю предлагается бежать в магазин за новым диском в ситуациях, когда любая другая ФС показала бы ещё уйму свободного места на разделе. Невозможность завершить операцию над логическим томом по причине нехватки свободного места - это тоже не самое страшное. Хуже всего то, что непривилегированный пользователь почти всегда может за достаточно короткое время в обход любых дисковых квот лишить всех свободного места. Выглядит это так (проверено для ядра Linux 5.12). На свежеинсталлированной системе запускается скрипт, который в цикле создаёт в домашней директории файлы с определенными именами, записывает в них данные по определенным смещениям и затем удаляет эти файлы. Через минуту работы этого скрипта ничего необычного не происходит. Через пять минут порция занятого места на разделе слегка увеличивается. Через два-три часа она достигает 50% (при начальном значении 15%). А после пяти-шести часов работы скрипт валится с ошибкой «нет свободного места на разделе». После этого вы уже не в состоянии записать на ваш раздел даже 4К файл. Происходит интересная ситуация: вы ничего на раздел в итоге не записали, а всё свободное место (порядка 85%) куда-то улетучилось. Анализ раздела, подвергнутого такой атаке, покажет множество узлов дерева, содержащих всего один айтем (объект, снабженный ключом), размером несколько байт. То есть, контент, который ранее занимал 15% дискового пространства оказался равномерно «размазанным» на весь раздел так, что новый файл записать уже некуда, ибо его ключ больше всех существующих, а свободные блоки на разделе закончились. Причем это всё происходит уже на базовой конфигурации Btrfs (безо всяких снапшотов, сабвольюмов и пр.), и не имеет значения то, как вы решили хранить тела файлов в той ФС (как «фрагменты» в дереве, или же как экстенты неформатированных блоков) - конечный результат будет один и тот же.
Я не знаю бтрфс даже настолько хорошо как intelfx, но если бы у неё были бы такие ужасные проблемы, то зачем бы использовал и развивал сам фкйсбук. На лоре как всегда плюются от типа полный отстой как в теме про монозвук, а в итоге оказывается ларчик просто открывался
Ну надо признать что у «самого фейсбука» достаточно специфичные use-case, не похожие ни на типичные сценарии типичного десктопа, ни даже более менее классического сервера. Так что фейсбук конечно развивает и btrfs, и systemd, но он может себе позволить и на rawhide-ветке сидеть.
скраб-это дополнительный функционал,который созволяет проверить и исправить поврежденные блоки,поблочно читая пул после,например,аварии.
это вмето того,чтобы перечитывать все файлы. но это не значит,что в случае повреждения блоков,напромер в зеркале,его обязательно запускать. при чтении поврежденных блоков они точно таи же прозрачно считаются с копии-скруб для этого запускать не требуется