БТРfs опять соснул

Это как палку с колесом сравнить - колесо круглое, лучше катится по дороге. А палкой удобнее бить тех, кто сравнивает btrfs

Говном эта недофс была говном и осталась

Спасибо что держишь в курсе. Выглядит так что через пару релизов можно будет переезжать на bcachefs. Было бы интересно посмотреть на эти же тесты на HDD.

Функциональность у дед4 и бтрфс разная. Бтрфс не нужна, если не использовать её продвинутые фичи. Надо сначала слепить башню из lvm+mdadm+ext4 и только потом её сравнивать с бтрфс.

В контексте того, что ext4fs наследник родственника ufs, это особенно символично.

Очередная троллерская тема. В прошлый раз сосал bcachefs, причем с какими-то уж совсем слабыми результами… И это, конечно же, доказывает, что это не у автора тех тестов данные, например, вместо записи slc-кеша «утрамбовываются»… нет это btrfs сосет. Очень ценное мнение, я после 7 лет использования btrfs перееду на xfs, который файловую систему уменьшать не умеет или на ext4, где нет сжатия как и RAID-режимов

продвинутые фичи

Отсутствие проблемы с инодами - это продвинутая фича?

xfs, который файловую систему уменьшать не умеет

это самое безобидное из её «качеств»

Использую btrfs на одном разделе как шакала, сжимающего файлы. Тормозит заметно, вот на ntfs такого не было (хотя там и сжатия zstd:9 не было).

НЕ для сжатия его нужно исппользовать, а для снапшотов! Иногда запускаешь команду какую, ошиьку сделал, а она тебе полсистемы снесла, откатился к последнему сохранению и живешь дальше.

А что тогда для сжатия использовать лучше?

Ext4 vs Btrfs

Мои тесты:

~   
❯ sudo mkdir -p /mnt/{btrfs,etx4}_vol

                                                                                                                              
~   
❯ sudo mount /dev/nvme2n1p2 /mnt/etx4_vol 
                                                                                                                              
~   
❯ sudo mount /dev/nvme2n1p3 /mnt/btrfs_vol
                                                                                                                              
~   
❯ findmnt /mnt/etx4_vol 
TARGET        SOURCE         FSTYPE OPTIONS
/mnt/etx4_vol /dev/nvme2n1p2 ext4   rw,relatime,stripe=32
  

# Смешанный тест чтения и записи 30% запись, 70% чтение                                                                                                                            
❯ sudo fio --name=mixed_rw --filename=/mnt/etx4_vol/testfile --size=1G --bs=4k --rw=randrw --rwmixread=70 --time_based --runtime=60 --ioengine=libaio --direct=1 --numjobs=4      
mixed_rw: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=1
...
fio-3.37
Starting 4 processes
...
Run status group 0 (all jobs):
   READ: bw=206MiB/s (216MB/s), 51.4MiB/s-51.4MiB/s (53.9MB/s-53.9MB/s), io=12.0GiB (12.9GB), run=60000-60001msec
  WRITE: bw=88.3MiB/s (92.5MB/s), 22.0MiB/s-22.1MiB/s (23.1MB/s-23.2MB/s), io=5296MiB (5553MB), run=60000-60001msec

Disk stats (read/write):
  nvme2n1: ios=3151938/1355437, sectors=25215616/10943152, merge=0/25, ticks=193093/16456, in_queue=209602, util=74.85%
                                                                                                                              
~   60s
❯ sudo fio --name=mixed_rw --filename=/mnt/btrfs_vol/testfile --size=1G --bs=4k --rw=randrw --rwmixread=70 --time_based --runtime=60 --ioengine=libaio --direct=1 --numjobs=4
mixed_rw: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=1
...
fio-3.37
Starting 4 processes
Jobs: 4 (f=4): [m(4)][100.0%][r=166MiB/s,w=71.3MiB/s]
...

Run status group 0 (all jobs):
   READ: bw=160MiB/s (168MB/s), 40.1MiB/s-40.1MiB/s (42.0MB/s-42.0MB/s), io=9618MiB (10.1GB), run=60001-60002msec
  WRITE: bw=68.9MiB/s (72.2MB/s), 17.2MiB/s-17.3MiB/s (18.0MB/s-18.1MB/s), io=4133MiB (4333MB), run=60001-60002msec
                                                                                                                              
~   60s
❯ 


~   
❯ uname --kernel-release 
6.10.3-arch1-2

Вместо сжатия лучше купить диск побольше.

А ещё файлы бэкапить не с живой системы лучше, а со снапшота.

Переносить систему на диск побольше как раз удобнее в btrfs или lvm - почти без простоя.

А почему zfs не добавят? Блобы же добавляют в ядро, вчем проблема?

НЕ для сжатия его нужно исппользовать, а для снапшотов! Иногда запускаешь команду какую, ошиьку сделал, а она тебе полсистемы снесла, откатился к последнему сохранению и живешь дальше.

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

Сначала они говорят, что блоатвер, распухший и тормозящий в современном мире это плохо. А потом, когда файловая система тормозит именно на своем главном функционале, но зато переливаясь свистопкрделками - это ок. Люди…

Ну так если данные очень сжимаемые, то почему нет? Места слишком много никогда не бывает.

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

А какие обидные?

например, у меня есть старый раздел с xfs, я хотел на нём врубить дедупликацию, но не вышло, так как версия слишком старая и только по-новой создавать и заливать данные

ещё в убунте есть таймер с fstrim раз в неделю, и он кладёт xfs на esxi нахер со временем

Были, вроде, какие-то статейки, что с небольшим уровнем сжатия общая производительность записи/чтения выше, чем без сжатия. Т.к. сжатие уменьшает объём непосредственно записываемой информации, а на архивацию современные процессоры тратят мало времени по сравнению с записью/чтением.

Тащемта, никто от фичастой ФС и не ждет суперскорости. Проблема бтрфс не в производительности, а в том, что она разваливается периодически. Да, у кого-то работает годами. Но ведь у кого-то и ломается? Играть в такую рулетку мало желающих. Проще использовать ext4 и вообще забыть, что существует какая-то там ФС.

Была фича, например, обнуление открытых файлов при жёстком ребуте. Вроде чинили...

«Я хотел включить отсутствующую фичу, а она не включилась» - это, конечно, возмутительно. Не, я понимаю, о чем ты, но для более новых ФС это неактуально же.

А расскажи про esxi, а то я не распарсил. У тебя fstrim’ы гостевых убунт убивают ФС гостя? А как быстро? А как ты понял, что дело в fstrim?

А у кого такой фичи не было?

«Я хотел включить отсутствующую фичу, а она не включилась» - это, конечно, возмутительно. Не, я понимаю, о чем ты, но для более новых ФС это неактуально же.

ext2 можно конвертнуть в ext4, а поднять версию xfs, не снося её - нельзя, возмутительно

У тебя fstrim’ы гостевых убунт убивают ФС гостя? А как быстро? А как ты понял, что дело в fstrim?

я таки попутал, хранилищо на vSAN
стоит гостевой убунтовый сервак, поднятый кем-то когда-то с данными на xfs, через пару лет сервис стал валиться по понедельникам, я залез в нужный промежуток, посмотрел iotop - в нём fstrim под потолком с 99.9%

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

Это в теории. А если диск - быстрый nvme PCIe v3+, то по-моему, никакого ускорения от сжатия нет.

Да она, кажись, уникальна )

Быстрое сжатие - обычно простой lzss. Работа memcpy в кэше против даже быстрой PCIe. Разница всё равно будет в разы.

Работа memcpy в кэше

Зачем в кеше, надо сравнивать чтение с диска, со сжатием и без.

Речь о распаковке. Один блок сжатых данных распакуется(из кэша, он же уже считан и передан процу) куда быстрее чтения и передачи дополнительных n блоков данных несжатых.

И ты еще себя, наверное, умным считаешь, ставя эти феспалмы. Нужны RAID1 на двух разных дисках с дублированием не только данных, но и заголовков, а так же «системных данных» (32 мегабайта информации для восстановления) и автоматическое снятие снапшотов. Ты же последний снапшот используешь для бекапа на другой диск в виде архивчика, да? Сейчас raid удалю буду архивы на отдельный диск сохранять ибо «надежнее»

Вот моя разметка:

+-----------+                                         +-----------+
| nvme0n1p1 |                                         | nvme1n1p1 |
+-----------+                                         +-----------+
      |                                                     |
      |                                                     |
      v                                                     v
+-----------+        +-----------------------+        +-----------+
|   luks1   |  ----> |     btrfs raid 1      | <----  |   luks2   |
+-----------+        +-----------------------+        +-----------+

И ты еще себя, наверное, умным считаешь, ставя эти феспалмы.

Скорее, читая, что ты пишешь.

Нужны RAID1 на двух разных дисках с дублированием не только данных, но и заголовков, а так же «системных данных» (32 мегабайта информации для восстановления)

Кому нужны? Речь шла о том, что особенного в btrfs, если что. Этот твой частный опыт в одном узком юзкейсе тут при чем? Синдромом утенка решил его на весь глобус натянуть?

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

Допустим.

Сейчас raid удалю буду архивы на отдельный диск сохранять ибо «надежнее»

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

Сохраняй архивы дальше. Это только для сервера применимо периодически архивчик снимать и на свой комп выкачивать либо в облако (на случай пожара в датацентре или падения метеорита).

С такой узостью взглядов, да в любую щель. Бекапы это, видите ли, только для сервера применимо. Самому не стыдно такую пургу нести?

Это только для сервера применимо периодически архивчик снимать и на свой комп выкачивать либо в облако (на случай пожара в датацентре или падения метеорита).

Нужно «либо» заменить на «и». Добавить даже ещё облаков, хранилищ. Тогда более-менее надежно можно бэкапить.

Была фича, например, обнуление открытых файлов при жёстком ребуте.

Фига ты вспомнил, это было лет 20 назад.

Не у всех есть 256 ГБ ОЗУ

Была фича, например, обнуление открытых файлов при жёстком ребуте.

Открытых на чтение?

И что значит «обнуление»? Размер?

из-под запущенный БД консистентный слепок

Я бы не расчитывал, что он будет консистентный. Что будет с незаконченными записями?

Я бы не расчитывал, что он будет консистентный.

Наверное, потому что не слышал про CoW.

Что будет с незаконченными записями?

Они будут зафиксированы в том состоянии, в котором были на момент создания снапшота.

Они будут зафиксированы в том состоянии, в котором были на момент создания снапшота.

Отлично. А где гарантии, что этот момент будет после всех записей, а не между ними?

БД умеет держать всегда консистентное состояние на диске, так что будут лежать в каком-нибудь WAL, готовые или неготовые к реплею соответственно. Тут те же гарантии, что и против уборщицы со шваброй.

Есть согласованность снапшотов на этот случай. Плюс ко всему, современные базы данных используют WAL (журналы транзакций) и механизмы блокировок для консистентности данных. В остальных случаях потребуется откат базы данных.

Что будет с незаконченными записями?

Пока ты не сделал fsync() результат твоей записи не определен. Ты можешь получить старый стейт (до записи), новый стейт (после записи) или смесь обои стейтов (часть данных старая часть новая). Посикс не регламентирует поведение.

Для обхода этого там где нужна атомарность применяют журналы (пример - тот самый WAL в PgSQL или Redo Logs в Oracle). В случае файловой системы с файлами - есть например опция монтирования data=journal в ext3/4.

В случае BTRFS ты получишь либо старые данные, либо новые данные (нет промежуточного состояния).

Ну и да, за все это придется платить - двукратной амплицикацией записи в случае журнала или «какой-то» амплицикацией в случае BTRFS/ZFS и прочих redirect-write ФС.

ПыСы - гипотетически BTRFS/ZFS будут лучше чем «тотально журналируемые ФС» при интенсивной записи если запись идет достаточно большими кусками. Фактически - ХЗ, смотреть надо - мне вот реально лень это проверять. Но вот запись мелкими блоками практически всегда в сложных ФС отстой, ибо большое количество апдейтов порождают оверхед в районе x5 (в лучших ситуациях) и временами можно увидеть и x10 (x9.5 я видел сам в тестах) и лечится это только приседаниями и подпрыгиваниями с костылями.

Бряхня, и меньше хватает! Вот прямо сейчас поглядел, у меня ARC отожрал всего лишь 63 гига.
Ну то есть ровно половину, как и есть по дефолту, и на 8Гб она работает ок, и даже на 4х.

Была фича, например, обнуление открытых файлов при жёстком ребуте.

Лично неоднократно пользовался этой фичей, что и явилось в свое время причиной ухода с XFS

Описание можно посмотреть тут: Bug 845233 - XFS regularly truncating files after crash/reboot