LINUX.ORG.RU

Анонсировано улучшение производительности Btrfs в ядре 6.9

 , ,

Анонсировано улучшение производительности Btrfs в ядре 6.9

0

3

В преддверии выпуска Linux Kernel 6.9, Давид Стерба из компании SUSE представил обновления для файловой системы Btrfs, которые включают в себя не только улучшение стабильности и исправление ошибок, но и оптимизацию производительности.

Нововведения в производительности Btrfs

Среди ключевых оптимизаций производительности Btrfs в Linux 6.9, Стерба выделяет следующие улучшения:

  • Ускорение логирования: незначительное ускорение ведения журнала, когда повторно выделяемая структура предварительно выделяется только один раз, что уменьшает задержку и уменьшает конфликт блокировок.

  • Повышение пропускной способности: незначительное увеличение пропускной способности (+6%), уменьшение конфликтов блокировок после очистки битов отложенного выделения, применимо к нескольким распространённым типам рабочих нагрузок.

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

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

Дополнительные улучшения BTRFS

В дополнение к упомянутым оптимизациям, Btrfs в Linux 6.9 получит исправление для сжатия Zstd, улучшения в отладочном коде, повышение качества обработки ошибок, подготовку к более детальному разделению блокировок секторов и рефакторинг кода. Все эти изменения направлены на усиление стабильности, безопасности и производительности файловой системы.

>>> Подробности

★★★

Проверено: hobbit ()
Последнее исправление: Dimez (всего исправлений: 5)

Ответ на: комментарий от rtxtxtrx

Страшно, очень страшно! Если бы мы знали что это такое, но мы не знаем что это такое. (c)

Это твоя интерпретация моей позиции. Не очень точная, но частично правдивая, так что ничего не имею против.

Ну тут после недавнего бага в ext4 о последней в свете мифической штабильности не может быть и речи напоминаю

Это печально, что ФС пытаются улучшить, но портят, отчего она начинает портить файлы. С другой стороны, где тысячи пострадавших? Наверняка проблема возникала в строго определенных условиях, так что большинство узнавало о ней из новостей и рассылок.

Ты асфальтоукладчик с гоночным болидом тоже сравниваешь?

Посмотри в удаленных, как один пытался сравнивать БТР с жигулями. Получилось не очень остроумно. Нет, обе файловых системы - это асфальтоукладчики, если уж на то пошло.

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

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

Оно и для БТР-FS верно

Нет, обе файловых системы - это асфальтоукладчики, если уж на то пошло

Ext4 не умет данные утрамбовывать, сжатия нет. Классическая ФС vs персональный черный ящик. Хотя ext4 тоже классическая условно, потому как классические в режиме записи на бобину работали без возможности перезаписи (ну кое где и сейчас на ленту пишут и это не анохронизм, а вполне себе экономичный способ хранения петабайтов данных)

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

Оно и для БТР-FS верно

А вот это уже повод искать информацию, насколько оно готово, или даже пробовать самому. Вроде как, некоторые btrfs уже в продакшн протащили.

Ext4 не умет данные утрамбовывать, сжатия нет.

А, так это развернутая метафора? Типа, ext4 - болид, потому что быстрее, а btrfs - асфальтоукладчик, потому что данные трамбует? Остроумно. Но можно слишком сильно уйти в сторону от сути вопроса, если сильно увлечься. Во-первых, скорости у обеих ФС различаются не на порядок-два, а на что-то в пределах 20% или даже 10%. Во-вторых, основная функция ФС - вовсе не сжатие и не снэпшоты, а файлы с метаданными хранить и давать интерфейсы для чтения и записи.

Мне это видится проще: ФС утилитарна и асфальтоукладчик утилитарен. А болид тут вообще не в тему, потому что болид - понты.

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

А кто Reiser сейчас сопровождает? Есть команда?

Когда-то давно, уже после того, как сам Рейзер был вынужденно отстранен от разработки, читал интервью с одним из ведущих ее разработчиков, и оно было полно боли и страданий; и сделал вывод, что от этой ФС надо держаться подальше

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

А кто Reiser сейчас сопровождает? Есть команда?

Ну какой-то небольшой движ там есть, судя по mail-листам.

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

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

Нет поддержки btrfs в Win10

Проснись,криокамера протекла.Уже 2 года как есть с цифровой подписью драйвер WinBtrfs с обслуживающими утилитами.Есть не совместимость по софту, некоторым играм не нравится фс.Так же от этого человека есть конвертер ntfs ->btrfs.Но там тоже лотерея,может не сконвертить.

maximnik0 ★★
()
Последнее исправление: maximnik0 (всего исправлений: 1)
Ответ на: комментарий от Vochatrak-az-ezm

А не подскажешь, насколько такое безопасно?

Ну я года полтора на постоянной основе использую два одинаковых SATA3 SSD, объединенные в одну файловую систему. Пока что полет нормальный.

Если что то произойдет с опциями монтирования, ФС упадет?

Не очень понял вопрос. Думаю, btrfs попросту не смонтируется, как и любая другая ФС. Вообще btrfs позволяет разбивать дисковое пространство на сабволюмы ака виртуальные разделы. Каждый сабволюм нужно монтировать отдельно, причем вроде бы можно использовать разные опции монтирования. Если что-то пойдет не так, то конкретно проблемный сабволюм не смонтируется. Например у меня в fstab три сабволюма - один под /, второй под /home, а третий хранит снапшоты первых двух.

UUID=28d494f4-ca5c-47f1-84a7-20ad5ff81323 /              btrfs  rw,noatime,discard,subvol=@          0      1
UUID=28d494f4-ca5c-47f1-84a7-20ad5ff81323 /home          btrfs  rw,noatime,discard,subvol=@home      0      2
UUID=28d494f4-ca5c-47f1-84a7-20ad5ff81323 /mnt/snapshots btrfs  rw,noatime,discard,subvol=@snapshots 0      2

Если умрет один носитель, часть данных со второго можно будет считать или хана?

Думаю, что хана. При объединении дисков без дублирования (RAID 0) btrfs равномерно распределяет содержимое каждого файла между носителями. Это ускоряет чтение/запись, но если один из носителей накроется, то практически никакие файлы восстановить не получится.

И как обстоят дела с объединением носителей имеющих разную скорость?

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

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

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

Не очень понял вопрос.

Ну вот допустим я случайно поправил fstab и по ошибке прописал диск из тех, на которых BtrFS. Система смонтирует его без второго и…

Вот собственно что произойдет? ФС и данные помрут, или достаточно будет вернуть фстаб к предыдущему состоянию и все смонтируется как и будет читаться?

Думаю, что хана. При объединении дисков без дублирования (RAID 0)

Так при объединении нескольких носителей с одну ФС, БтрФС же не создает рейд? По идее фс должна просто растянуться на блоки второго устройства (без «шахматной» записи). Или я не правильно понял как это работает?

Vochatrak-az-ezm ★★
()
Ответ на: комментарий от Vochatrak-az-ezm

Система смонтирует его без второго и…

Не смонтирует. Если хоть один носитель в массиве отсутствует или поврежден, то вся ФС целиком не смонтируется и ты с ней ничего не сможешь сделать. Не могу представить сценарий, когда btrfs можно сломать неправильными опциями монтирования.

достаточно будет вернуть фстаб к предыдущему состоянию и все смонтируется как и будет читаться?

Ага.

Так при объединении нескольких носителей с одну ФС, БтрФС же не создает рейд? По идее фс должна просто растянуться на блоки второго устройства (без «шахматной» записи).

Ааа, так ты хочешь просто объединение дисков без рейда. Ну да, так тоже можно. Указываешь опцию -d single при создании ФС и тогда она просто растянется на два диска.

mkfs.btrfs -d single /dev/sda1 /dev/sdb1

В такой конфигурации файлы по идее должны записываться в линейном порядке, а не шахматном. Сначала все данные будут записываться на /dev/sda1, а когда место на нем закончится, то новые файлы будут записываться уже на /dev/sdb1. Соответственно если один из дисков сдохнет, то по крайней мере часть уцелевших файлов возможно удастся вытащить с другого диска.

Но я например создал именно рейд (-d raid0). Шахматный порядок ускоряет чтение/запись, а для сохранности данных лучше всего регулярно делать бэкапы.

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

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

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

ну raid-0, если какой-то диск сдох, то все потеряно, а raid-1 хз что будет, если диск неожиданно откажет, но при сбоях он монтироваться откажется без -o degraded

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