LINUX.ORG.RU
ФорумTalks

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

 , ,


0

4

На ядре 6.11 всё плохо. Отставание в два раза от ext4 и XFS (листать вниз до geometric mean of all test results):
https://www.phoronix.com/review/linux-611-filesystems/3

Вот ещё куча бенчмарков. БТРfs в одном потоке тоже отстаёт прилично:
https://www.youtube.com/watch?v=_RKSaY4glSc&t=1065s

Bcachefs в одних тестах немного лучше btrfs, а в других хуже.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

+-----------+                                         +-----------+
| nvme0n1p1 |                                         | nvme1n1p1 |
+-----------+                                         +-----------+
      |                                                     |
      |                                                     |
      v                                                     v
+-----------+        +-----------------------+        +-----------+
|   luks1   |  ----> |     btrfs raid 1      | <----  |   luks2   |
+-----------+        +-----------------------+        +-----------+
rtxtxtrx ★★
()
Последнее исправление: rtxtxtrx (всего исправлений: 1)
Ответ на: комментарий от rtxtxtrx

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

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

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

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

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

Допустим.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

no-dashi-v2 ★★★
()
Ответ на: комментарий от GAMer

В теории. А на практике будет как тут, 10-кратное замедление. Да и даже при последовательном доступе к данным наблюдаются ситуации, когда:

Without compression the full image backup runs easily at 600-700 Mbits.
With compression, either lzo or zstd:1, the throughput is half of it 250-300 Mbits.

Нафига такое счастье?

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

А на практике

btrfs with compress=zstd:1

zstd против lz4, чуешь разницу?
Хотя там райзен 3900, переваривать и zstd должен, видать, SUBJ )

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

ты сам хоть ссылку читал, там даже в комментариях написали почему автор чудак? а по второй ссылке btrfs в виртуалке и на файле (vhd, ага)… я выше кинул реальные тесты на последнем стабильном ядре, а на хрюниксе твоем вообще ядро 6.11 нестабильное. btrfs при чтении/записи на 20-25% медленее - для меня это нормальная плата за сжатие логов, дампов баз и тп текстовых файлов в 17-20 раз и наличие легковесных снапшотов

rtxtxtrx ★★
()
Последнее исправление: rtxtxtrx (всего исправлений: 2)
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)