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

тем, что нет цифры 4 в названии

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

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

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

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

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

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

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

чем это лучше 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

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

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

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

Сжатием

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

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

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

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

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

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

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

нужно на SSD 256GB

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

Reflink умеет и XFS.

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

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

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

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

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

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

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

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

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

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

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

1. хватает.
2. дуалбут не нужен.

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

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

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

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

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

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

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

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

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

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

Значит мои знания устарели. 🤷🏻

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

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

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

После потери питания или краша системы не нужен ритуал с fsck и можно просто продолжить работать.

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

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

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

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

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

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

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

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

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

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

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

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

Сбой питания -> fsck,

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

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

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

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

Думал о таком: Удаление диска из BTRFS без сохранения файлов

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

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

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

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

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

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

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

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

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

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

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

tldr -u
Downloading tldr pages to .../.local/share/tldr

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

переписал

нет конечно - не трогал ничего, но все что падает в .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

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

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

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

🤦

.local

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

.cache

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ॐ.