VP
Зачем? 😉
Size: a a a
2021 May 24
A
Я так страдаю
VP
Ой, какое интересное интервью... Особенно интересно про
btrfs И да, вас не глючит. Чувак пилит ReiserFS.
VP
— Как ты оцениваешь прогресс в разработке Btrfs? Эта ФС избавилась от детских болезней? Как ты её для себя позиционируешь — как ФС «для дома» или и для корпоративного применения тоже?
Не избавилась. Всё то, о чём я упоминал 11 лет назад, актуально и поныне. Одна из проблем Btrfs, делающая последнюю непригодной для серьёзных нужд, - это проблема свободного места. Я уж не говорю о том, что пользователю предлагается бежать в магазин за новым диском в ситуациях, когда любая другая ФС показала бы ещё уйму свободного места на разделе. Невозможность завершить операцию над логическим томом по причине нехватки свободного места - это тоже не самое страшное. Хуже всего то, что непривилегированный пользователь почти всегда может за достаточно короткое время в обход любых дисковых квот лишить всех свободного места. Выглядит это так (проверено для ядра Linux 5.12). На свежеинсталлированной системе запускается скрипт, который в цикле создаёт в домашней директории файлы с определенными именами, записывает в них данные по определенным смещениям и затем удаляет эти файлы. Через минуту работы этого скрипта ничего необычного не происходит. Через пять минут порция занятого места на разделе слегка увеличивается. Через два-три часа она достигает 50% (при начальном значении 15%). А после пяти-шести часов работы скрипт валится с ошибкой "нет свободного места на разделе". После этого вы уже не в состоянии записать на ваш раздел даже 4К файл. Происходит интересная ситуация: вы ничего на раздел в итоге не записали, а всё свободное место (порядка 85%) куда-то улетучилось. Анализ раздела, подвергнутого такой атаке, покажет множество узлов дерева, содержащих всего один айтем (объект, снабженный ключом), размером несколько байт. То есть, контент, который ранее занимал 15% дискового пространства оказался равномерно "размазанным" на весь раздел так, что новый файл записать уже некуда, ибо его ключ больше всех существующих, а свободные блоки на разделе закончились. Причем это всё происходит уже на базовой конфигурации Btrfs (безо всяких снапшотов, сабвольюмов и пр.), и не имеет значения то, как вы решили хранить тела файлов в той ФС (как "фрагменты" в дереве, или же как экстенты неформатированных блоков) - конечный результат будет один и тот же.
Не избавилась. Всё то, о чём я упоминал 11 лет назад, актуально и поныне. Одна из проблем Btrfs, делающая последнюю непригодной для серьёзных нужд, - это проблема свободного места. Я уж не говорю о том, что пользователю предлагается бежать в магазин за новым диском в ситуациях, когда любая другая ФС показала бы ещё уйму свободного места на разделе. Невозможность завершить операцию над логическим томом по причине нехватки свободного места - это тоже не самое страшное. Хуже всего то, что непривилегированный пользователь почти всегда может за достаточно короткое время в обход любых дисковых квот лишить всех свободного места. Выглядит это так (проверено для ядра Linux 5.12). На свежеинсталлированной системе запускается скрипт, который в цикле создаёт в домашней директории файлы с определенными именами, записывает в них данные по определенным смещениям и затем удаляет эти файлы. Через минуту работы этого скрипта ничего необычного не происходит. Через пять минут порция занятого места на разделе слегка увеличивается. Через два-три часа она достигает 50% (при начальном значении 15%). А после пяти-шести часов работы скрипт валится с ошибкой "нет свободного места на разделе". После этого вы уже не в состоянии записать на ваш раздел даже 4К файл. Происходит интересная ситуация: вы ничего на раздел в итоге не записали, а всё свободное место (порядка 85%) куда-то улетучилось. Анализ раздела, подвергнутого такой атаке, покажет множество узлов дерева, содержащих всего один айтем (объект, снабженный ключом), размером несколько байт. То есть, контент, который ранее занимал 15% дискового пространства оказался равномерно "размазанным" на весь раздел так, что новый файл записать уже некуда, ибо его ключ больше всех существующих, а свободные блоки на разделе закончились. Причем это всё происходит уже на базовой конфигурации Btrfs (безо всяких снапшотов, сабвольюмов и пр.), и не имеет значения то, как вы решили хранить тела файлов в той ФС (как "фрагменты" в дереве, или же как экстенты неформатированных блоков) - конечный результат будет один и тот же.
A
Я вам в личку скинул зенит человеческого развития
tf
Вы таки не поверите, но использование zram в качестве ФС очень распространено и у линукс-домохозяек
VP
Собственно для всякого ленивого кеша... А на tmpfs тащем-та чуть менее чем везде кладут /tmp
tf
Ах да, а тмпфс уже давно дефолт!
tf
Так что на бытовом уровне это и так каждый день происходит
VP
Подвергнуть такой атаке остальные файловые системы из апстрима вам не удастся (что бы вам там ни говорили). Причину проблемы я уже давно объяснил: это полное извращение в Btrfs понятия B-дерева, что делает возможным его спонтанное или намеренное вырождение. В частности, при некоторых нагрузках ваша ФС в процессе эксплуатации будет непрерывно "разваливаться" и сама, без посторонней помощи. Понятно, что всевозможные "поджимающие" фоновые процессы спасут дело только на индивидуальных десктопах. На коллективных же серверах злоумышленник всегда будет в состоянии их "опередить". Системный администратор даже не сможет определить, кто именно над ним издевался. Быстрее всего исправить эту проблему в Btrfs можно лишь восстановив структуру регулярного B-дерева, т.е. заново перепроектировав дисковый формат и переписав существенную часть кода Btrfs. Это займёт 8-10 лет вместе с отладкой при условии что разработчики чётко следовали оригинальным статьям по соответствующим алгоритмам и структурам данным, а не играли в "испорченный телефон", как это принято (и поощряется) в "Linux way". Сюда ещё надо прибавить время, необходимое разработчикам на то, чтобы понять всё это. Вот тут уже сложнее. Во всяком случае, 10 лет на понимание им не хватило. Ну, а до этого можете не уповать на чудо. Оно не произойдёт в виде опции монтирования "про которую мы с вами не знали", или в виде патча, который приготовить "всего-то делов". Для каждого такого скоропалительного "исправления" я предъявлю новый сценарий вырождения. B-деревья - это одна из моих излюбленных тем, и должен сказать, что вольности в обращении с собой эти структуры не терпят!
VP
Вашу Машу. B-Tree вполне успешно использовалось в полуоси, на
HPFS ещё с 1988-го года, когда её придумали и апофеозом которой стала HPFS386.VP
— Хотелось бы попросить прокомментировать прекращение поддержки Btrfs в RHEL.
Тут особо нечего комментировать, всё предельно ясно. Она же была у них "technology preview". Вот, и не прошла это самое "preview". Не висеть же вечно этому ярлыку! А запустить ущербный by-design продукт с полной поддержкой они не могут. RHEL - это энтерпрайз, то есть прописанные товарно-денежные отношения. Red Hat не может издеваться над пользователями, как это происходит в листе рассылки Btrfs. Просто представьте ситуацию: клиент, заплативший свои кровные за диск и ещё вам за поддержку, хочет понять, куда делось его дисковое пространство, после того, как он ничего не записал. Что вы ему на это ответите? Далее. В число клиентов Red Hat входят известные крупные банки, биржи. Представьте, что будет, если они подвергнутся DoS-атакам, основанным на упомянутой уязвимости в Btrfs. Как вы думаете, кто за это ответит? Тем, кто собрался ткнуть пальцем в строчку лицензии GPL, где написано, что автор ни за что не отвечает, сразу скажу: "спрячьте её подальше!" Ответит Red Hat, причём так, что мало не покажется! Но я знаю, что Red Hat-у такого рода проблемы не грозят, учитывая их особенно сильную команду QA-инженеров, с которыми мне довелось плотно поработать в своё время.
Тут особо нечего комментировать, всё предельно ясно. Она же была у них "technology preview". Вот, и не прошла это самое "preview". Не висеть же вечно этому ярлыку! А запустить ущербный by-design продукт с полной поддержкой они не могут. RHEL - это энтерпрайз, то есть прописанные товарно-денежные отношения. Red Hat не может издеваться над пользователями, как это происходит в листе рассылки Btrfs. Просто представьте ситуацию: клиент, заплативший свои кровные за диск и ещё вам за поддержку, хочет понять, куда делось его дисковое пространство, после того, как он ничего не записал. Что вы ему на это ответите? Далее. В число клиентов Red Hat входят известные крупные банки, биржи. Представьте, что будет, если они подвергнутся DoS-атакам, основанным на упомянутой уязвимости в Btrfs. Как вы думаете, кто за это ответит? Тем, кто собрался ткнуть пальцем в строчку лицензии GPL, где написано, что автор ни за что не отвечает, сразу скажу: "спрячьте её подальше!" Ответит Red Hat, причём так, что мало не покажется! Но я знаю, что Red Hat-у такого рода проблемы не грозят, учитывая их особенно сильную команду QA-инженеров, с которыми мне довелось плотно поработать в своё время.
VP
Как глядь интересно...
Кроме того, с низкоуровневыми менеджерами томов вы не сможете организовать полноценные снимки (snapshots). С LVM и в ZFS-подобных ФС вы можете делать только локальные снимки, но никак не глобальные. Локальные снимки позволяют моментально откатывать только регулярные файловые операции. A операции с логическими томами (добавление / удаление устройств) вам никто там не откатит. Давайте рассмотрим это на примере. В некоторый момент времени, когда у вас имеется логический том из двух устройств А и В, содержащий 100 файлов, вы делаете снимок S системы и затем создаете ещё одну сотню файлов. После этого вы добавляете к вашему тому устройство С, и наконец откатываете вашу систему к снимку S. Вопрос: сколько файлов и устройств содержит ваш логический том после отката к S? Файлов, как вы уже догадались, будет 100, но вот устройств будет 3 - это те же устройства A, B и C, хотя, на момент создания снимка в системе было всего два устройства (A и B). Операция добавления устройства C не откатилась, и если вы сейчас удалите устройство C из компьютера, то это закорраптит ваши данные, так что перед удалением вам вам нужно будет сначала провести дорогостоящую операцию удаления устройства из логического тома с перебалансировкой, которая раскидает все данные с устройства C на устройства A и B. А вот если бы ваша ФС поддерживала глобальные снимки, такая перебалансировка бы не потребовалась, и после моментального отката к S вы бы могли смело удалить устройство C из компьютера.
Кроме того, с низкоуровневыми менеджерами томов вы не сможете организовать полноценные снимки (snapshots). С LVM и в ZFS-подобных ФС вы можете делать только локальные снимки, но никак не глобальные. Локальные снимки позволяют моментально откатывать только регулярные файловые операции. A операции с логическими томами (добавление / удаление устройств) вам никто там не откатит. Давайте рассмотрим это на примере. В некоторый момент времени, когда у вас имеется логический том из двух устройств А и В, содержащий 100 файлов, вы делаете снимок S системы и затем создаете ещё одну сотню файлов. После этого вы добавляете к вашему тому устройство С, и наконец откатываете вашу систему к снимку S. Вопрос: сколько файлов и устройств содержит ваш логический том после отката к S? Файлов, как вы уже догадались, будет 100, но вот устройств будет 3 - это те же устройства A, B и C, хотя, на момент создания снимка в системе было всего два устройства (A и B). Операция добавления устройства C не откатилась, и если вы сейчас удалите устройство C из компьютера, то это закорраптит ваши данные, так что перед удалением вам вам нужно будет сначала провести дорогостоящую операцию удаления устройства из логического тома с перебалансировкой, которая раскидает все данные с устройства C на устройства A и B. А вот если бы ваша ФС поддерживала глобальные снимки, такая перебалансировка бы не потребовалась, и после моментального отката к S вы бы могли смело удалить устройство C из компьютера.
N
Сейчас там есть новая CoW фс интересная:
https://bcachefs.org
https://bcachefs.org
VP
Так что, "будущее файловых систем в Линукс" - это очередной сильно распиаренный, но мало пригодный к использованию софт. После Btrfs с большой вероятностью место такого "будущего" займёт Bcachefs, представляющая собой ещё одну попытку скрестить Linux block layer с файловой системой (дурной пример заразителен). И что характерно: там те же проблемы, что и в Btrfs. Я давно это подозревал, а потом как-то не удержаляся и заглянул в код - так и есть! Авторы Bcachefs и Btrfs, создавая свои ФС, активно пользовались чужими исходниками, мало что в них понимая. Ситуация очень напоминает детскую игру "испорченный телефон". И я примерно представляю, как будет происходить включение этого кода в ядро. Собственно "грабли" никто не увидит (на них все будут наступать потом). После многочисленных придирок к стилю кода кода, обвинению в несуществующих нарушениях, и пр. будет делаться заключение о "лояльности" автора, о том, насколько он хорошо "взаимодействует" с остальными разработчиками, и как успешно всё это потом можно будет продавать корпорациям. Конечный же результат никого не заинтересует. Лет двадцать назад, может быть, бы и заинтересовал, но сейчас вопросы ставятся по-другому: получится ли это раскрутить так, чтобы ближайший десяток лет определённые люди оказались трудоустроены. А задаваться вопросом о конечном результате, увы, не принято.
N
👍👍👍👍
Мощь
Мощь