Лучшие практики и будущее btrfs на десктопе

По поводу шифрования - btrfs поверх luks прекрасно работает.

Но куда, куда медленнее fscrypt.

И городить luks на каждом из нескольких дисков для нормальной работы btrfs поверх — та ещё гимнастика.

Возможно. Я не замечаю на nvme.

Но куда, куда медленнее fscrypt

С чего бы? Криптография та же самая примерно.

сейчас более модно bcachefs

3. Per subvolume raid profile

из-за этого я ушёл на lvm

им так сложно считать df, но они вот-вот научатся.

btrfs до сих пор df считает так себе.

Особенность CoW. Доверять df что в btrfs, что в zfs не стоит.

Когда в Fedora перешли на btrfs, а затем подумали, они не нашли решения и отказались от физического swap в пользу zram.

Я и без всякого бтрфс отказался от свопа, зачем он вообще нужен в нынешние времена?

Что такое dty? Dirty?

С ZFS df вполне нормально работает. Это косяк только btrfs.

Я и без всякого бтрфс отказался от свопа, зачем он вообще нужен в нынешние времена?

Для s2disk.

А им сейчас кто-то пользуется? Оно вообще работает?

Да и да.

btrfs до сих пор df считает так себе.

А как оно должно считать, если есть сжатие, reflink и прочее COW ?

Btrfs не поддерживает файл подкачки на нескольких дисках, но нафиг она нужна на одном диске — не понятно.

А в чём прикол свопа не нескольких? У меня подключены ещё два SSD и что будет, если я раскидаю своп по ним?

Интересно знать, а зачем шифровать, допустим, /etc или /usr? Даже что в ~/ и то мало что требует шифрования. А вот swap на диске как раз требует шифрование, но мало кто это делает.

У btrfs нет будущего на десктопе. У него даже настоящего нет.

Я ничего не говорил о шифровании /etc или /usr. Что и где требует шифрования — зависит от модели угроз. С fscrypt можно шифровать отдельные каталоги, не разменивая полосу и зедержки всей файловой системы на безопасность, как с luks.

Но можно придумать и такую модель угроз, в которой шифрование /etc с /usr будет оправдано.

Прикол в том, что с btrfs и несколькими дисками swap вообще нельзя сделать без использования альтернатив btrfs.

Например?

Вы про swapfile или раздел на диске?

У btrfs нет будущего на десктопе. У него даже настоящего нет.

Вы говорите, что Linux free as in beer. Горькое, но справедливое замечание. Это всё лишено всякого смысла. Стоит принять меры.

Точно, swapfile на многодисковой btrfs создать нельзя, просто отдать диск целиком и не думать про разделы, будто в 1997, нельзя.

Вот в LVM я могу в одной VG собирать тома каких угодно профилей: raid1 для нужного, raid0 для быстрого на одних и тех же PV.

На днях собирал raid0 из двух дисков (hdd) и решил поверхностно глянуть скорость работы. Копировал директорию на 400gb с кучей файлов (с pci4 ssd на raid0 hdd):

32m 35s - xfs raid0 (md рейд)

26m 59s - btrfs raid 0 nocow

24m 13s - btrfs raid 0 zstd3

26m 29s - ext4 raid0 (md рейд)

Я к тому, что при создании такого гибкого raid0 на lvm стоит присмотреться к скорости в результате. raid0 lvm для скорости на диске рядом с raid1 выглядит прям сомнительной затеей, особенно на операциях чтения.

Я бы побоялся делать RAID-0 вообще, хоть для скорости, хоть для чего.

Лично у меня на десктопе тоже только raid0 — скорость! Но как было бы круто делать btrfs subvolume create -d raid1 ~/quality_memes просто для отдельного каталога.

Только смешные картинки сейчас наиболее перспективная валюта, неохота терять.

Не потерять смешные картинки поможет резервное копирование, а не RAID1, он вообще не для этого нужен.

Всё так!

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

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

Ха-ха, да, возможно 😅

Write amplification в реальности

Я от btrfs ожидал заметного прироса физической записи на SSD. Но в моём случае по динамике Total_LBAs_Written я значимой разницы не заметил: в нагрузке где на ext4 был прирост 5 КБ/c, на btrfs стал 10 КБ/c; но где был 150 КБ/c — такой и остался. Только это в моём самом примитивном сценарии: профили Firefox и текстовые файлы в vim.

Тестирование 🔥

Я взял пустой SSD и протестировал, как два крайних случая отразятся на физической записи на накопитель в разных конфигурациях ФС:

• последовательная запись — копирование корневого раздела локалхоста на ФС;
• агрессивные малые модификации файлов — sqlite insert в индексируемые БД, 32 экземпляра с данными из теста pts.

Ядро 6.8.0-49-generic #49-Ubuntu, SSD ширпотреб Samsung SSD 860 EVO.

Ниже данные прироста 241 Total_LBAs_Written, приведённые к килобайтам.

Безотвественный вывод

Что вы и так знали: в последовательной записи btrfs пишет столько же или меньше, где есть сжатие. На модификациях файлов в экстремальных случаях объём физической записи до 3 раз выше, чем у ext4. Это заметно, но не достаточно для убийства SSD.

Что вы могли не знать: btrfs filesystem defragment на живой файловой системе с 50 GB данных у меня даёт запись примерно 50 GB на накопители. Практики btrfs-kiddies, такие как еженедельные запуски defrag и balance, могут увеличивать объёмы физической записи на порядки. И вот их уже может быть достаточно для убийства бытового SSD с DWPD 0.1.

Могу рекомендовать лучшую альтернативу для btrfsmaintenance: defrag98.com