Roman
По отзывам реальных пользователей, особенно синолоджи, бртфс часто теряет разделы с данными
Так же, по отзывам реальных пользователей (и меня в том числе) бутер не только не терял данные, но и фс не развалилась при выходе из строя ssd. И благополучно переехала на другой. Плюсом добавлю сюда фсбук и федору с опенсусе
Sergey
По тестам похороникса бтрфс была быстрее зфс раза в 2
Я не претендую на правильно проведённый тест.
Ivan
2-3 месяца назад на синолоджи выходила обновка, которая теряла данные если у тебя btrfs 😃
Evgenii
2-3 месяца назад на синолоджи выходила обновка, которая теряла данные если у тебя btrfs 😃
это не проблема btrfs, а больные менеджеры синолоджи они случайно включили поддержку BTRFS в младших моделях ранее, а затем пофиксили этот баг.
Олег
это не проблема btrfs, а больные менеджеры синолоджи они случайно включили поддержку BTRFS в младших моделях ранее, а затем пофиксили этот баг.
Нет это проблема BRTFS, потому что он вечный комбайн с недопилами и вечными новшествами, в место допилов существующих проблем, с проблемами с логигами (на математическом уровне), на хабре детальный обзор был от крупного интегратора с выводами. Проблема в синолоджи далеко не в младших бывает, а синолоджи показателен ибо рейд по умолчанию стороит на BRTFS и как следствие имеет проблемы более показательные в силу распространенности
Roman
Да https://kb.synology.com/en-us/DSM/tutorial/What_was_the_RAID_implementation_for_Btrfs_File_System_on_SynologyNAS
George
желаю только успеха btrfs, но после лаконичности cli у zfs оно для меня устроено очень не удобно
George
плюс к этому отсутствие последовательности в подходах сильно мешает
LordMerlin
Москва не сразу строилась
Mikhail
Привет чат! Вопрос к знатокам кода. Есть массовые чтения из кэша. При чтение из кэша (arc_read) делает zfs_blkptr_verify для проверки что ничего не поломалось. Внутри zfs_blkptr_verify берётся RW блокировка в режиме чтения на SPA. При массовом чтении наблюдаем что все уписаются в получении mutex-а для данной RW блокировки: ffffffff8cd0680e osq_lock+0x7e ([kernel.kallsyms]) ffffffff8d5dbb44 __mutex_lock.isra.8+0x84 ([kernel.kallsyms]) ffffffff8d5dbf53 __mutex_lock_slowpath+0x13 ([kernel.kallsyms]) ffffffff8d5dbf8c mutex_lock+0x2c ([kernel.kallsyms]) ffffffffc2023a3b spa_config_exit+0x3b ([kernel.kallsyms]) ffffffffc20891fa zfs_blkptr_verify+0x3fa ([kernel.kallsyms]) ffffffffc1f81b4b arc_read+0x21b ([kernel.kallsyms]) ffffffffc1f955e8 dbuf_read_impl.constprop.30+0x2a8 ([kernel.kallsyms]) ffffffffc1f95bdf dbuf_read+0x1bf ([kernel.kallsyms]) ffffffffc1f9f5d8 dmu_buf_hold_array_by_dnode+0x128 ([kernel.kallsyms]) ffffffffc1fa02f9 dmu_read_uio_dnode+0x49 ([kernel.kallsyms]) ffffffffc1fa03e5 dmu_read_uio_dbuf+0x45 ([kernel.kallsyms]) ffffffffc207ccd9 zfs_read+0x139 ([kernel.kallsyms]) ffffffffc20b8d60 zpl_iter_read+0xe0 ([kernel.kallsyms]) ffffffff8cee0712 new_sync_read+0x122 ([kernel.kallsyms]) ffffffff8cee32f9 __vfs_read+0x29 ([kernel.kallsyms]) ffffffff8cee33a9 vfs_read+0x99 ([kernel.kallsyms]) или ffffffff8cd0680e osq_lock+0x7e ([kernel.kallsyms]) ffffffff8d5dbb44 __mutex_lock.isra.8+0x84 ([kernel.kallsyms]) ffffffff8d5dbf53 __mutex_lock_slowpath+0x13 ([kernel.kallsyms]) ffffffff8d5dbf8c mutex_lock+0x2c ([kernel.kallsyms]) ffffffffc2023af0 spa_config_enter+0x40 ([kernel.kallsyms]) ffffffffc2089211 zfs_blkptr_verify+0x411 ([kernel.kallsyms]) ffffffffc1f81b4b arc_read+0x21b ([kernel.kallsyms]) ffffffffc1f955e8 dbuf_read_impl.constprop.30+0x2a8 ([kernel.kallsyms]) ffffffffc1f95bdf dbuf_read+0x1bf ([kernel.kallsyms]) ffffffffc1f9f5d8 dmu_buf_hold_array_by_dnode+0x128 ([kernel.kallsyms]) ffffffffc1fa02f9 dmu_read_uio_dnode+0x49 ([kernel.kallsyms]) ffffffffc1fa03e5 dmu_read_uio_dbuf+0x45 ([kernel.kallsyms]) ffffffffc207ccd9 zfs_read+0x139 ([kernel.kallsyms]) ffffffffc20b8d60 zpl_iter_read+0xe0 ([kernel.kallsyms]) ffffffff8cee0712 new_sync_read+0x122 ([kernel.kallsyms]) ffffffff8cee32f9 __vfs_read+0x29 ([kernel.kallsyms]) ffffffff8cee33a9 vfs_read+0x99 ([kernel.kallsyms]) Вопрос собственно зачем брать SPA config блокировки при каждом чтение из кэша?
George
Привет чат! Вопрос к знатокам кода. Есть массовые чтения из кэша. При чтение из кэша (arc_read) делает zfs_blkptr_verify для проверки что ничего не поломалось. Внутри zfs_blkptr_verify берётся RW блокировка в режиме чтения на SPA. При массовом чтении наблюдаем что все уписаются в получении mutex-а для данной RW блокировки: ffffffff8cd0680e osq_lock+0x7e ([kernel.kallsyms]) ffffffff8d5dbb44 __mutex_lock.isra.8+0x84 ([kernel.kallsyms]) ffffffff8d5dbf53 __mutex_lock_slowpath+0x13 ([kernel.kallsyms]) ffffffff8d5dbf8c mutex_lock+0x2c ([kernel.kallsyms]) ffffffffc2023a3b spa_config_exit+0x3b ([kernel.kallsyms]) ffffffffc20891fa zfs_blkptr_verify+0x3fa ([kernel.kallsyms]) ffffffffc1f81b4b arc_read+0x21b ([kernel.kallsyms]) ffffffffc1f955e8 dbuf_read_impl.constprop.30+0x2a8 ([kernel.kallsyms]) ffffffffc1f95bdf dbuf_read+0x1bf ([kernel.kallsyms]) ffffffffc1f9f5d8 dmu_buf_hold_array_by_dnode+0x128 ([kernel.kallsyms]) ffffffffc1fa02f9 dmu_read_uio_dnode+0x49 ([kernel.kallsyms]) ffffffffc1fa03e5 dmu_read_uio_dbuf+0x45 ([kernel.kallsyms]) ffffffffc207ccd9 zfs_read+0x139 ([kernel.kallsyms]) ffffffffc20b8d60 zpl_iter_read+0xe0 ([kernel.kallsyms]) ffffffff8cee0712 new_sync_read+0x122 ([kernel.kallsyms]) ffffffff8cee32f9 __vfs_read+0x29 ([kernel.kallsyms]) ffffffff8cee33a9 vfs_read+0x99 ([kernel.kallsyms]) или ffffffff8cd0680e osq_lock+0x7e ([kernel.kallsyms]) ffffffff8d5dbb44 __mutex_lock.isra.8+0x84 ([kernel.kallsyms]) ffffffff8d5dbf53 __mutex_lock_slowpath+0x13 ([kernel.kallsyms]) ffffffff8d5dbf8c mutex_lock+0x2c ([kernel.kallsyms]) ffffffffc2023af0 spa_config_enter+0x40 ([kernel.kallsyms]) ffffffffc2089211 zfs_blkptr_verify+0x411 ([kernel.kallsyms]) ffffffffc1f81b4b arc_read+0x21b ([kernel.kallsyms]) ffffffffc1f955e8 dbuf_read_impl.constprop.30+0x2a8 ([kernel.kallsyms]) ffffffffc1f95bdf dbuf_read+0x1bf ([kernel.kallsyms]) ffffffffc1f9f5d8 dmu_buf_hold_array_by_dnode+0x128 ([kernel.kallsyms]) ffffffffc1fa02f9 dmu_read_uio_dnode+0x49 ([kernel.kallsyms]) ffffffffc1fa03e5 dmu_read_uio_dbuf+0x45 ([kernel.kallsyms]) ffffffffc207ccd9 zfs_read+0x139 ([kernel.kallsyms]) ffffffffc20b8d60 zpl_iter_read+0xe0 ([kernel.kallsyms]) ffffffff8cee0712 new_sync_read+0x122 ([kernel.kallsyms]) ffffffff8cee32f9 __vfs_read+0x29 ([kernel.kallsyms]) ffffffff8cee33a9 vfs_read+0x99 ([kernel.kallsyms]) Вопрос собственно зачем брать SPA config блокировки при каждом чтение из кэша?
если речь про spa_config_enter, то по блейму он появился здесь и там есть мотивация https://github.com/openzfs/zfs/commit/dc04a8c757d7df91efbca05491174112540f6e7a а вот не потеряли ли флаг в процессе - хороший вопрос, видимо в arc_read оно позже появилось, надо по истории коммитов и блейму попрыгать
nikolay
Привет чат! Вопрос к знатокам кода. Есть массовые чтения из кэша. При чтение из кэша (arc_read) делает zfs_blkptr_verify для проверки что ничего не поломалось. Внутри zfs_blkptr_verify берётся RW блокировка в режиме чтения на SPA. При массовом чтении наблюдаем что все уписаются в получении mutex-а для данной RW блокировки: ffffffff8cd0680e osq_lock+0x7e ([kernel.kallsyms]) ffffffff8d5dbb44 __mutex_lock.isra.8+0x84 ([kernel.kallsyms]) ffffffff8d5dbf53 __mutex_lock_slowpath+0x13 ([kernel.kallsyms]) ffffffff8d5dbf8c mutex_lock+0x2c ([kernel.kallsyms]) ffffffffc2023a3b spa_config_exit+0x3b ([kernel.kallsyms]) ffffffffc20891fa zfs_blkptr_verify+0x3fa ([kernel.kallsyms]) ffffffffc1f81b4b arc_read+0x21b ([kernel.kallsyms]) ffffffffc1f955e8 dbuf_read_impl.constprop.30+0x2a8 ([kernel.kallsyms]) ffffffffc1f95bdf dbuf_read+0x1bf ([kernel.kallsyms]) ffffffffc1f9f5d8 dmu_buf_hold_array_by_dnode+0x128 ([kernel.kallsyms]) ffffffffc1fa02f9 dmu_read_uio_dnode+0x49 ([kernel.kallsyms]) ffffffffc1fa03e5 dmu_read_uio_dbuf+0x45 ([kernel.kallsyms]) ffffffffc207ccd9 zfs_read+0x139 ([kernel.kallsyms]) ffffffffc20b8d60 zpl_iter_read+0xe0 ([kernel.kallsyms]) ffffffff8cee0712 new_sync_read+0x122 ([kernel.kallsyms]) ffffffff8cee32f9 __vfs_read+0x29 ([kernel.kallsyms]) ffffffff8cee33a9 vfs_read+0x99 ([kernel.kallsyms]) или ffffffff8cd0680e osq_lock+0x7e ([kernel.kallsyms]) ffffffff8d5dbb44 __mutex_lock.isra.8+0x84 ([kernel.kallsyms]) ffffffff8d5dbf53 __mutex_lock_slowpath+0x13 ([kernel.kallsyms]) ffffffff8d5dbf8c mutex_lock+0x2c ([kernel.kallsyms]) ffffffffc2023af0 spa_config_enter+0x40 ([kernel.kallsyms]) ffffffffc2089211 zfs_blkptr_verify+0x411 ([kernel.kallsyms]) ffffffffc1f81b4b arc_read+0x21b ([kernel.kallsyms]) ffffffffc1f955e8 dbuf_read_impl.constprop.30+0x2a8 ([kernel.kallsyms]) ffffffffc1f95bdf dbuf_read+0x1bf ([kernel.kallsyms]) ffffffffc1f9f5d8 dmu_buf_hold_array_by_dnode+0x128 ([kernel.kallsyms]) ffffffffc1fa02f9 dmu_read_uio_dnode+0x49 ([kernel.kallsyms]) ffffffffc1fa03e5 dmu_read_uio_dbuf+0x45 ([kernel.kallsyms]) ffffffffc207ccd9 zfs_read+0x139 ([kernel.kallsyms]) ffffffffc20b8d60 zpl_iter_read+0xe0 ([kernel.kallsyms]) ffffffff8cee0712 new_sync_read+0x122 ([kernel.kallsyms]) ffffffff8cee32f9 __vfs_read+0x29 ([kernel.kallsyms]) ffffffff8cee33a9 vfs_read+0x99 ([kernel.kallsyms]) Вопрос собственно зачем брать SPA config блокировки при каждом чтение из кэша?
А чем отслеживали syscall’ы?
Mikhail
А чем отслеживали syscall’ы?
профилирование perf-ом
Mikhail
если речь про spa_config_enter, то по блейму он появился здесь и там есть мотивация https://github.com/openzfs/zfs/commit/dc04a8c757d7df91efbca05491174112540f6e7a а вот не потеряли ли флаг в процессе - хороший вопрос, видимо в arc_read оно позже появилось, надо по истории коммитов и блейму попрыгать
прикинул число чтений из arc-а. Получилось что в пределе 10M чтений из кэша на 100 физ. ядрах. Поскольку блокировка spa_config_lock_t->scl_lock общая для всех нитей, то в целом время на одну блокировку порядка 100наносекунд, т.е порядок времени доступа к памяти в NUMA режиме. Вот бы попилить данный лок на ядра, тем более что читаем в READER режиме.
riv
если подождать, то ерроры появляются на абсолютно всех дисках
А если часть дисков, или хотя бы один, соеденить с sata-контролоером на мат плате или другим sas-контроллером?
riv
нет места, всё занято
Последний безумный вариант... USB?!
Александр🇷🇺
!kick
Александр🇷🇺
@neurox выдай мне прав
Fedor
они у тебя есть
Александр🇷🇺
они у тебя есть
Не, Кик не получился
Александр🇷🇺
Через ! kick
Fedor
теперь должно
Fedor
выданы
Eugen
Хлопцы! Подскажите с какой версии zfs повысила скорость работы с nvme?
Evgenii
для меня - с той, где trim появился. Речь не про nvme, а про SSD в целом
Evgenii
автотрим по умолчанию до сих пор выключен. Включите, будет хорошо
Eugen
А, я думал уже. Просто перелез на 2.0.6 сo старой фряшной zfs, бодрее все бегает.
Eugen
Можно патч накатить
Та оно уже в проде, пусть работает) А автотрим включу, спасибо.
Eugen
для будущих машин что за патч? Он надежен воообще?)
Vladislav
автотрим по умолчанию до сих пор выключен. Включите, будет хорошо
Так? so zpool set autotrim=on and a periodic zpool trim is the recommended approach. I'd suggest a cron job (or systemd timer if you prefer) to run zpool trim at the same frequency as you run scrub your pool, which is set as the second Sunday of every month by default (have a look at /etc/cron.d/zfsutils-linux), but on different days of the month so the two aren't running simultaneously.
Art
Хлопцы! Подскажите с какой версии zfs повысила скорость работы с nvme?
DirectIO в 3.0 завезут, и не только это, там много крутых фич будет https://www.ixsystems.com/blog/openzfs-3-0-introduced-at-developer-summit/
Nick
непонятно только когда оно случится :( Очень и директио жду и поддержку немспейсов...
Nick
и ни одного актуального роадмапа нигде нет
Nick
https://github.com/openzfs/zfs/milestones https://openzfs.org/wiki/Roadmap Кому бы об этом написать?
Alexander
может вот так выйдет @gmelikov )))по роадмапу))
Ivan
непонятно только когда оно случится :( Очень и директио жду и поддержку немспейсов...
собирай, тестируй, сообщай о багах. ускоришь выход стабильного релиза.
George
и ни одного актуального роадмапа нигде нет
Роадмап на саммите показывали в виде презы, но он тоже примерный
central
Народ, так и не появилось бенчмарка для оценки влияния сжатия zfs на производительность?
central
все очень индивидуально
так для этого и нужен бенчмарк, чтобы у себя его запустить
Ivan
так для этого и нужен бенчмарк, чтобы у себя его запустить
ааа. вроде кто-то писал свой скриптик для оценки хранения контента.
Fedor
Практически во всех наблюдаемых случаях сжатие увеличивало лейтенси.
central
есть же вроде ссд который умеют сами аппаратно шифровать данные, это не помогает, или zfs не может так
Eugen
Практически во всех наблюдаемых случаях сжатие увеличивало лейтенси.
То есть сжатие по сути уменьшает производительность?
Fedor
Производительность - это сумма метрик. Некоторый эффект сжатие даёт. Насколько будет влиять, зависит от типа нагрузки.
Fedor
И увеличивает тоже)
И такое бывает, да :)
Fedor
Например, может увеличить скорость записи ценой лейтенси
central
а что вообще по аппаратной поддержи у процов алгоритмов что использует zfs для сжатия, такое бывает?
DOK ꧁꧂
С какой стати процам это подлерживать
Fedor
Кстати, не замечал в процах аппаратного сжатия что-то)
central
С какой стати процам это подлерживать
ну точно процессоры умеют в аппаратное кодирования многих кодеков никого не удивляет
Fedor
Шифрование это про другое
DOK ꧁꧂
Сжатие ускоряет если файл целиком читать писать а не долбиться в разные части
George
Народ, так и не появилось бенчмарка для оценки влияния сжатия zfs на производительность?
Берётся нужный бенч и гоняется с и без сжатия, главное удостовериться что бенч не нули пишет. У того же fio можно задать паттерн и степень сжимаемости данных. Но от этой степени и зависит эффективность. И компрессию от шифрования надо отличать.
George
Lz4 (который по дефолту) компрессит примерно со скоростью 800мбайт/сек на поток, а декомпрессит - 4000мбайт/сек на поток, зависит от проца конечно
George
Для gzip можно на интеловые сопроцессоры qat оффлоадить сжатие в zfs, кстати
Evgenii
ZSTD vs LZ4 vs none (Windows 11 system disk, bs=8kb) zfs get compression,compressratio,used rpool/data/vm-100-disk-0x rpool/data/vm-100-disk-0y NAME PROPERTY VALUE SOURCE rpool/data/vm-100-disk-0x compression zstd local rpool/data/vm-100-disk-0x compressratio 1.29x - rpool/data/vm-100-disk-0x used 30.6G - rpool/data/vm-100-disk-0y compression lz4 local rpool/data/vm-100-disk-0y compressratio 1.17x - rpool/data/vm-100-disk-0y used 33.5G - rpool/data/vm-100-disk-0z compression off local rpool/data/vm-100-disk-0z compressratio 1.00x - rpool/data/vm-100-disk-0z used 39.5G - rpool/data/vm-100-disk-0g compression gzip local rpool/data/vm-100-disk-0g compressratio 1.29x - rpool/data/vm-100-disk-0g used 30.5G - Intel i7-10700, Samsung 970 evo plus 2tb -> zfs send rpool/data/vm-100-disk-0@mac | zfs recv -v -o compression=zstd rpool/data/vm-100-disk-0x receiving full stream of rpool/data/vm-100-disk-0@mac into rpool/data/vm-100-disk-0x@mac received 40.5G stream in 48 seconds (865M/sec) zfs send rpool/data/vm-100-disk-0@mac | zfs recv -v -o compression=lz4 rpool/data/vm-100-disk-0y receiving full stream of rpool/data/vm-100-disk-0@mac into rpool/data/vm-100-disk-0y@mac received 40.5G stream in 41 seconds (1013M/sec) zfs send rpool/data/vm-100-disk-0@mac | zfs recv -v -o compression=off rpool/data/vm-100-disk-0z receiving full stream of rpool/data/vm-100-disk-0@mac into rpool/data/vm-100-disk-0z@mac received 40.5G stream in 49 seconds (847M/sec) zfs send rpool/data/vm-100-disk-0@mac | zfs recv -v -o compression=gzip rpool/data/vm-100-disk-0g receiving full stream of rpool/data/vm-100-disk-0@mac into rpool/data/vm-100-disk-0g@mac received 40.5G stream in 119 seconds (349M/sec) Ryzen 5950->
Fedor
Спасиб за наводку
George
Сжатие ускоряет если файл целиком читать писать а не долбиться в разные части
Но большинство алгоритмов всё равно стрим данных побьют на куски и их будут сжимать. Попробуйте нули как-нибудь сжать, посмотрите что итоговый размер у большинства будет зависеть от размера на входе. Ну и в zfs сжатие в любом случае поблочно
Evgenii
То есть сжатие по сути уменьшает производительность?
сейчас ответим на этот вопрос.. я добавлю тест отправки фс в несжатый том
Eugen
Я просто до этого момента думал что коль сжатие на лету и проц справляется, то инфа записывается меньшими кусками, и читается так же, то есть IOpsы должны вырасти
Evgenii
ZSTD vs LZ4 vs none (Windows 11 system disk, bs=8kb) zfs get compression,compressratio,used rpool/data/vm-100-disk-0x rpool/data/vm-100-disk-0y NAME PROPERTY VALUE SOURCE rpool/data/vm-100-disk-0x compression zstd local rpool/data/vm-100-disk-0x compressratio 1.29x - rpool/data/vm-100-disk-0x used 30.6G - rpool/data/vm-100-disk-0y compression lz4 local rpool/data/vm-100-disk-0y compressratio 1.17x - rpool/data/vm-100-disk-0y used 33.5G - rpool/data/vm-100-disk-0z compression off local rpool/data/vm-100-disk-0z compressratio 1.00x - rpool/data/vm-100-disk-0z used 39.5G - rpool/data/vm-100-disk-0g compression gzip local rpool/data/vm-100-disk-0g compressratio 1.29x - rpool/data/vm-100-disk-0g used 30.5G - Intel i7-10700, Samsung 970 evo plus 2tb -> zfs send rpool/data/vm-100-disk-0@mac | zfs recv -v -o compression=zstd rpool/data/vm-100-disk-0x receiving full stream of rpool/data/vm-100-disk-0@mac into rpool/data/vm-100-disk-0x@mac received 40.5G stream in 48 seconds (865M/sec) zfs send rpool/data/vm-100-disk-0@mac | zfs recv -v -o compression=lz4 rpool/data/vm-100-disk-0y receiving full stream of rpool/data/vm-100-disk-0@mac into rpool/data/vm-100-disk-0y@mac received 40.5G stream in 41 seconds (1013M/sec) zfs send rpool/data/vm-100-disk-0@mac | zfs recv -v -o compression=off rpool/data/vm-100-disk-0z receiving full stream of rpool/data/vm-100-disk-0@mac into rpool/data/vm-100-disk-0z@mac received 40.5G stream in 49 seconds (847M/sec) zfs send rpool/data/vm-100-disk-0@mac | zfs recv -v -o compression=gzip rpool/data/vm-100-disk-0g receiving full stream of rpool/data/vm-100-disk-0@mac into rpool/data/vm-100-disk-0g@mac received 40.5G stream in 119 seconds (349M/sec) Ryzen 5950->
готово.
Evgenii
- lz4 ускорило запись на диск на 17% и сэкономило 17% места. - zstd сэкономило 29% места