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)

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

не я серьезно, ext4 и так хорош, но чем btrfs лучше, должно же быть что то во что ext4 не умеет - иначе смысла нет или только не для таких как все.

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

Вот коротко, преимущества Btrfs перед Ext4:

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

  • Btrfs поставляется с алгоритмами сжатия, присутствующими в файловой системе, что позволяет сжимать данные на уровне файловой системы сразу при записи в систему. В Ext4 такой встроенной поддержки сжатия нет.

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

  • Btrfs поддерживает CoW, поэтому пользователи могут создавать снимки файлов, доступные для записи и только для чтения. В Ext4 эта функция отсутствует.

  • Btrfs может обрабатывать больше данных, чем Ext4.

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

чем это лучше ext4?

Сжатием, например.

[whbex@wbx-desktop ~]$ sudo compsize /home
Processed 825105 files, 483631 regular extents (908577 refs), 459874 inline.
Type       Perc     Disk Usage   Uncompressed Referenced  
TOTAL       82%       55G          67G         110G       
none       100%       49G          49G          73G       
zstd        32%      5.8G          17G          36G       
prealloc   100%       29M          29M         234M       
[whbex@wbx-desktop ~]$ findmnt /home
TARGET
      SOURCE                FSTYPE OPTIONS
/home /dev/nvme0n1p3[/home] btrfs  rw,relatime,seclabel,compress=zstd:1,ssd,discard=async,space_cache=v2,subvolid=256,subvol=/home
whbex ★★
()
Ответ на: комментарий от DrRulez

Btrfs может обрабатывать больше данных, чем Ext4.

вот мы и подошли к самому интересному - скорость быстрей? то есть если разметить винт в ext4 и замерить скорость, а потом разметить в btrfs и замерить ее, то скорость винта в btrfs будет выше? я почему именно таким интересуюсь - для меня главное скорость, а все эти сжатия и снимки нафиг нинужно, я конечно все понимаю - сохранность данных важная вещь, но меня больше скорость беспокоит… ну так что можно сказать с полной уверенностью что btrfs на 30-50% быстрей ext4?

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

Сжатием

опять это слово, что оно хоть означает? больше что ли можно напихать? мне это не нужно - винты в основном менее чем на 1\3 забиты.

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

быстрее - не будет

спасибо большое это все что я хотел знать

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

опять это слово, что оно хоть означает?

Засчёт процессора прозрачно сжать сжимаемые данные на диске. Экономит место иногда, а просадки производительности нет.

мне это не нужно

А мне нужно на SSD 256GB.

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

нужно на SSD 256GB

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

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

А еще она не может удалить файлы с раздела, если на нем кончилось место.

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

но меня больше скорость беспокоит… ну так что можно сказать с полной уверенностью что btrfs на 30-50% быстрей ext4?

Более сложная ФС всегда будет медленнее более простой. FAT16 вообще огонь. :-)

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

опять это слово, что оно хоть означает? больше что ли можно напихать? мне это не нужно - винты в основном менее чем на 1\3 забиты.

на HDD меньше данных пишется. Если процессор быстрый, а узкое место - скорость записи, то будет ускорение записи.

AS ★★★★★
()

Исчё по поводу преимуществ btrfs.

Поддержка btrfs в grub позволяет делать /boot не в отдельном разделе, а прямо в корневом @ subvol, вместе со всей операционной системой. И после этого снапшоты btrfs наконецто обретают смысл. Напрягает только почему в timeshift захардкожено название корневой директории в @ и @home для /home. Поэтому при инсталяциие надо всегда переименовывать субтома btrfs в правильные названия. И теперь можно переключать снапшоты например между версиями федоры или ядрами с установленными драйверами невидии и без них. Тоесть можно сделать снапшот в 38 федоре, обновиться на 39, а затем безпроблем восстановить 38 федору, и обратно.

Есть ли недостатки? да есть.

  1. Не хватаем возможности выбора снапшота в меню grub.

  2. Нет поддержки btrfs в Win10, если бы была, можно былобы наконец прекратить мучения с разбиением диска на партишены, а в идеале размечать диск в один партишен или вообще без него, форматировать btrfs на весь диск.

В общем btrfs лучшая фс.

FriendshipIsMagic
()
Последнее исправление: FriendshipIsMagic (всего исправлений: 1)
Ответ на: комментарий от FriendshipIsMagic
  1. хватает.
  2. дуалбут не нужен.

после этого снапшоты btrfs наконецто обретают смысл

Да нет, смыслом они обладают по природе своей.

token_polyak ★★★★★
()
Последнее исправление: token_polyak (всего исправлений: 3)
Ответ на: комментарий от DrRulez

Дополню, что btrfs умеет объединять несколько разделов или физических дисков в единую файловую систему. Например можно взять два SSD диска по 256 Гб и объединить их средствами btrfs в один большой диск на 512 Гб, как в RAID 0. Или зеркалировать данные, как в RAID 1. Вроде даже можно на лету добавлять новые разделы/диски к уже существующей файловой системе.

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

Не хватаем возможности выбора снапшота в меню grub.

Поставь пакет grub-btrfs.

Сможешь загружаться в любой снапшот по желанию.

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

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

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

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

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

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

Устарели, да не совсем.

Во-первых, никто не знает, какие конкретно алгоритмы зашиты в тот или иной SSD. Если хорошие, то учет особенностей памяти NAND со стороны ФС не повредит. Если плохие, то даже поможет. Пока это выглядит так: какой-нибудь EVO можно мучить чем угодно, но с каким-нибудь Netac можно и перестраховаться, но вовсе не обязательно. Какому-нибудь Crucial я бы доверился безоговорочно, но все равно это гадание на кофейной гуще.

Во-вторых, флешки и SD-карточки довольно тупы по сравнению с SSD. Но они, если не мучить их малинками, не пишутся и не читаются постоянно. Если это перенос файлов, носитель раньше умрет от механики или статики, чем износится. Если это использование в фотоаппарате, в Bluetooth-колонке, в магнитоле, в телефоне, обычно преобладает WORM (write once, read many). На этих носителях можно всерьез сравнивать разные ФС, но ценность таких рассуждений преимущественно академическая. На практике лучше озаботиться переносимостью и выбирать между FAT, exFAT, NTFS, ext4.

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

Или не продолжить.

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

Меня такие люди удивляют просто. По существу сказать - нечего, но жажда писать, зачастую, преобладает над способностью думать.

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

Меня такие люди удивляют просто. По существу сказать - нечего, но жажда писать, зачастую, преобладает над способностью думать.

Главное не обнаружить, что говоришь с зеркалом.

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

Или не продолжить.

Возможно. Но из-за ext4 я не раз попадал в неприятные ситуации на десктопах/ноутах, простоям на серваках и на fsck+debugfs потрачено несколько дней чистого времени. А с btrfs это пока только потенциальная возможность и даже выход из строя с полной потерей данных на диске не перекроет потерянное на ext4 время, если это вдруг когда-нибудь да случится.

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

Но из-за ext4 я не раз попадал в неприятные ситуации

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

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

Интересный опыт, но все же хотелось бы знать причины и условия.

Сбой питания -> fsck, который далеко не всегда проходит в автоматическом режиме и за десять секунд. А если на железке десятки ТБ хдд с постоянной активной записью, то быстро её не поднимешь.

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

Т.е. под проблемами ты подразумевал, что fsck проходит долго?

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

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

узкое место - скорость записи

я это и имел ввиду - будет ли винт размеченый в btrfs читать\писать быстрей чем размеченый в ext4 и на сколько быстрее это будет происходить

процессор быстрый

да насрать какой - даже 4-ый пень быстрее любого винта и по этому у меня все в памяти живет и zram и tmpfs и .cache и .local

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

там как раз то, что должно переживать перезагрузку

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

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

и что же это? логины пароли которые ты везде разные и сложные придумал? ну так придумай везде одинаковое и простое что бы не мучаться…

facepalm.jpeg Это чтобы сразу увели все пароли? Отличный путь!

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

У приложений помимо конфигов бывают данные. Они как раз лежат в .local

tldr -u
Downloading tldr pages to .../.local/share/tldr
PRN
()
Ответ на: комментарий от Vidrele

Сижу на %подставь название%, потому что

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

стабильность и производительность по сравнению с ext4

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

Ты асфальтоукладчик с гоночным болидом тоже сравниваешь? Вроде как оба ездить умеют, но предназачены как бы для разных целей. Btrfs идеален для рабочего компа, где случайное удаление одного файла, может создать море проблем. А так это, конечно, никакая не революционная файловая система. Nilfs, ZFS, Btrfs, Cachefs… у них у всех были прототипы еще в 80-х

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

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

Если речь про RAID-1, то чтение происходит так: читаем блок с устройства A, читам блок с устройства B, …, повторяем. Ну а скорость записи будет равна самому медленному устройству. Не знаю как включить асинхронную запись, которая создаст больше проблем чем решит

rtxtxtrx ★★
()

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

Анонсировано

Но вряд ли будет реализовано. ☺

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

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

О, ты весь-весь-весь используемый софт софт переписал, чтобы он не следовал XDG, суперхерой!

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

чтобы сразу увели все пароли

ноборот не увели - они же в оперативной памяти и живут не долго

бывают данные

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

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

чтобы сразу увели все пароли

ноборот не увели - они же в оперативной памяти и живут не долго

У тебя всё нормально с логикой? Ты их передаёшь при авторизации и они все могут быть перехвачены. Если аккаунты можно как-то связать, каждый пойманный пароль будет попробован для входа на всех твоих известных аккаунтах.

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

переписал

нет конечно - не трогал ничего, но все что падает в .cache и .local мне действительно не нужно, единственное что оставил это

export XDG_CACHE_HOME="/tmp/.cache"
[ -d "${XDG_CACHE_HOME}" ] || (
        mkdir -p "${XDG_CACHE_HOME}"
        chmod 0700 "${XDG_CACHE_HOME}"
)
cp -ax /home/void/.cache/fontconfig /tmp/.cache
export XDG_DATA_HOME="/tmp/.local/share"
[ -d "${XDG_DATA_HOME}" ] || (
        mkdir -p "${XDG_DATA_HOME}"
        chmod 0700 "${XDG_DATA_HOME}"
)
cp -ax /home/void/.local/share/fonts /tmp/.local/share

что бы система использовала мои шрифты и для быстроты из памяти читала

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

нормально с логикой

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

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

🤦

.local

Тогда почему ты не сделаешь /usr/share в tmpfs? И $XDG_DATA_HOME, и /usr/share (он же $XDG_DATA_DIRS) выполняют одну функцию.

.cache

Видимо, у тебя ещё не происходило заполнение tmpfs на 100%, когда ты даже удалить оттуда ничего не можешь по причине “no space left”.

Но это твой комплюхтер, ты можешь городить на нём любой колхоз… Только потом не удивляйся проблемам на ровном месте. ☺

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

логика такая - пока я радом с машиной ее безопасности ничего не угрожает

Ты выходишь с этой машины в интернет? Если да, то угрожает, и скорее всего не у тебя украдут данные, а ты сам их отдашь. ^_~

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

у тебя ещё не происходило заполнение tmpfs на 100%

нет не происходило - у меня ее до жопы

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

я это и имел ввиду - будет ли винт размеченый в btrfs читать\писать быстрей чем размеченый в ext4 и на сколько быстрее это будет происходить

Да кто же тебя знает? Одно дело, если ты аудио/видео в mp3/mp4 хранишь, которые не сжимаются, другое - если текстовики. Open Document, кстати, тоже сам по себе архив.

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

Ты выходишь с этой машины в интернет?

да конечно в этом смысл любой машины

ты сам их отдашь. ^_~

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

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

все что падает в .cache и .local мне действительно не нужно

Когда ты поставишь что-то, что использует .local ты рискуешь потерять свои данные.

man mkdir 
...
       -m, --mode=MODE
              set file mode (as in chmod), not a=rwx - umask
...

На сколько твой колхоз с .local и прочим ускорил систему?

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

что использует .local

да всё испрользует - все пароли хранятся там, но если надо ввести от лора пароль это проще пареной репы, а если от телеги то это тот еше геморой… у тебя есть телега? тогда это не для тебя - у меня же нет телеги, а на лоре и из под анонимуса можно постить.

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

у тебя есть телега? тогда это не для тебя - у меня же нет телеги, а на лоре и из под анонимуса можно постить.

И вот, о братья, благородная истина о начале страдания. Истинно! — тот зачаток страдания лежит в жажде, обрекающей на возрождение, в этой ненасытной жажде, что влечёт человека то к тому, то к другому, связана с людскими усладами, в вожделении страстей, в вожделении будущей жизни, в вожделении продления настоящей. Такова, о братья, благородная истина о начале страданий.

ॐ.

token_polyak ★★★★★
()
Последнее исправление: token_polyak (всего исправлений: 4)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.