Fedor
http://dtrace.org/blogs/brendan/2012/01/09/activity-of-the-zfs-arc/
Fedor
И нужен ли префетч кстати
Fedor
https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSUnderstandingARCHits
Владимир
начиная от типа есть zstd-fast например, заканчивая плотностью сжатия
Владимир
самые плотные кстати очень тупые)), самые производительные быстрее даже чем lz4
Владимир
к примеру я на постгрескуле юзаю zfs и там использую zstd-fast-2, по производительности в сравнении остальными на запись показал себя лучше всего, даже лучше чем без сжатия
Владимир
при этом кстати для файлов постгрескула оказался самым эффективным, может конечно есть какие-то особенности именно с моими данными, но он оказался лотнее самых плотных вариантов)), места экономит лучше всего
Владимир
272933 zstd-fast-2
541017 off
Разница в весе файла таблицы постгрескул
Autumn
272933 zstd-fast-2
541017 off
Разница в весе файла таблицы постгрескул
сравнение с другими типами сжатия есть? это гораздо более интересна инфа, чем просто результат сжатия, эээх мне бы сравнение
Владимир
Владимир
но блин, только не докапывайтесь)
Владимир
покажу как есть
Владимир
Провёл тесты по записи и чтению файла таблицы Postgresql весом 541017 байт
Рейтинг по занятому в итоге месту
272933 zstd-fast-2
272941 zstd-fast-1
272949 gzip-5
272949 zstd-fast-3
272953 lz4
272953 zstd-fast-4
272957 gzip
272957 gzip-8
272965 gzip-9
272965 zstd-14
272973 gzip-2
272973 gzip-4
272973 gzip-6
272973 zstd-5
272973 zstd-9
272977 on
272981 gzip-7
272981 zstd-12
272981 zstd-15
272981 zstd-4
272989 gzip-1
272989 zstd
272989 zstd-1
272989 zstd-17
272989 zstd-18
272989 zstd-19
272993 zstd-fast-5
272997 gzip-3
272997 zstd-3
272997 zstd-8
273005 zstd-10
273005 zstd-11
273013 zstd-16
273013 zstd-2
273013 zstd-7
273021 zstd-6
273029 zstd-13
274985 zstd-fast-6
283061 zstd-fast-7
291305 zstd-fast-8
308045 zstd-fast-10
315405 zstd-fast-9
355113 lzjb
465545 zstd-fast-50
494373 zstd-fast-30
498029 zstd-fast-20
513641 zstd-fast-60
514425 zstd-fast-40
515649 zstd-fast-70
515925 zstd-fast-80
516257 zstd-fast-90
516533 zstd-fast-100
516733 zle
517493 zstd-fast-500
518281 zstd-fast-1000
541017 off
Рейтинг по затраченному времени на запись
zstd-fast-2 0m5,792s
zstd-fast-4 0m5,810s
zstd-fast-6 0m5,825s
zstd-3 0m5,888s
zstd-fast-10 0m5,916s
gzip-1 0m5,929s
gzip-3 0m5,966s
zstd 0m5,977s
zstd-8 0m6,027s
zstd-fast-1 0m6,261s
zstd-1 0m6,676s
zstd-2 0m6,710s
zstd-5 0m6,807s
zstd-fast-9 0m6,815s
gzip-9 0m6,839s
zstd-9 0m6,843s
zstd-fast-3 0m6,860s
on 0m6,919s
lzjb 0m6,931s
zstd-13 0m6,940s
zstd-fast-50 0m6,991s
zstd-fast-7 0m7,244s
zstd-fast-100 0m7,295s
zstd-fast-1000 0m7,575s
zstd-fast-20 0m7,625s
zstd-fast-90 0m7,626s
zstd-10 0m7,662s
zstd-fast-30 0m7,723s
zstd-fast-70 0m7,941s
off 0m7,970s
zstd-fast-60 0m8,660s
zstd-fast-5 0m8,903s
zstd-fast-80 0m9,103s
lz4 0m9,104s
gzip-7 0m9,717s
zstd-fast-8 0m9,818s
zstd-6 0m9,947s
gzip-5 0m10,313s
gzip-8 0m10,591s
zstd-fast-500 0m10,755s
zstd-14 0m10,772s
zstd-fast-40 0m11,190s
zle 0m11,265s
gzip-4 0m11,301s
zstd-4 0m11,403s
gzip-2 0m12,094s
zstd-7 0m12,775s
gzip-6 0m14,020s
gzip 0m18,246s
zstd-12 0m20,912s
zstd-11 0m23,507s
zstd-18 0m28,346s
zstd-16 0m29,338s
zstd-15 0m38,595s
zstd-19 0m50,360s
zstd-17 0m53,334s
Рейтинг по затраченному времени на чтение
zstd-4 0m3,856s
lz4 0m3,883s
zstd-3 0m3,910s
zstd-11 0m3,911s
zstd-fast-8 0m3,936s
zstd-fast-6 0m3,937s
zstd-fast-5 0m3,943s
zstd-fast-2 0m3,983s
zstd-7 0m3,995s
gzip-4 0m4,012s
zstd-fast-3 0m4,025s
gzip 0m4,030s
gzip-5 0m4,082s
lzjb 0m4,107s
zstd-1 0m4,188s
gzip-6 0m4,204s
on 0m4,239s
zstd-fast-4 0m4,506s
zstd-12 0m4,667s
gzip-7 0m5,045s
zstd-fast-1000 0m5,061s
gzip-8 0m5,262s
zstd-fast-100 0m5,282s
zstd-fast-20 0m5,292s
zstd-fast-70 0m5,334s
zstd-fast-10 0m5,419s
gzip-2 0m5,476s
zstd-6 0m5,714s
zle 0m5,732s
zstd-fast-30 0m5,944s
zstd-10 0m6,170s
off 0m6,203s
zstd-fast-500 0m6,378s
zstd-fast-60 0m6,636s
zstd-14 0m6,650s
zstd-fast-40 0m6,916s
zstd-15 0m7,089s
gzip-9 0m7,716s
gzip-3 0m7,818s
zstd-fast-7 0m7,873s
zstd-fast-80 0m7,900s
zstd-16 0m8,115s
zstd-8 0m8,438s
zstd 0m8,515s
zstd-5 0m8,530s
zstd-2 0m8,540s
gzip-1 0m8,634s
zstd-13 0m8,958s
zstd-9 0m9,546s
zstd-fast-90 0m9,556s
zstd-19 0m9,591s
zstd-18 0m9,807s
zstd-17 0m11,449s
zstd-fast-50 0m13,015s
zstd-fast-9 0m14,598s
Тест проводился в SSD пуле с одним vdev mirror из INTEL_SSDSC2KG960G8 с принудительным sync и выключенным arc кешем и ресайзблоком 8кб процессор AMD 3950X
Autumn
но блин, только не докапывайтесь)
че докапываться, мне интересно что есть для опыта, у меня просто нет времени такой объем тестов провести
Владимир
это один из тестов, они будут отличаться в зависимости от того какие данные пишем, на какие диски, и на каком проце))
Autumn
Норм тесты, в принципе подтверждают мои личные выводы, zstd +-= lz4, всякие около zstd варианты, типа zstd-4|5 или zstd-fast тоже находятся около стандартного zstd, все что плотнее сжимает типа zstd-15 сразу же дает снижение скорости и нагрузку на ЦП, остальное в пределах погрешности. Единственное, что странные показатели теста на запись, там zstd дал 6 cек, lz4 9 сек, а ON 7сек, при этом on включает дефолтную компрессию lz4, у меня результаты были всегда равны, что-то повлияло на тест видать, раз результат почти на 25% изменился, ну или я что-то не знаю про дефолтный режим ON.
Autumn
Так ещё и zstd c zstd-3 разнятся
ну там мизерная разница как я вижу, как раз говорит о том что ztsd по уморчанию и включает 3 уровень, а так да, на запись чутка "поплыло"
Autumn
в моих тестах тоже есть погрешность но я все тесты минимум три раза прогоняю и погрешность ну до 5%, но я на ненагруженной системе их делаю, а иногда я был удивлен, все три круга одного теста вообще выдавали полностью идентичный результат, цифра в цифру =), тут странный почти 25% разброс, я думаю что-то в этот момент повлияло на систему, но в общем можно предсказать поведение системы и я для себя делаю выводы что лучше включать компрессию и без заморочек - стандартную lz4 или zstd, это даст хороший результат по копрессии и скорости и при этом минимальный оверхэд, экономить вырубая компрессию я пока что не вижу смысла, как и накручивать что-то типа zstd-5 и выше, или gzip мучать
Станислав
Всё именно так. Тестил на постгре-базах. Больших.
Как по мне, не очень важен тип базы. Важно то, чем она наполнена. Например, у меня есть БД (mysql), в которой в определенный момент стали хранить электронные письма со всем содержимым (pdf, jpeg...). В итоге сила сжатия упала с 4х до 1.8х
Станислав
в моих тестах тоже есть погрешность но я все тесты минимум три раза прогоняю и погрешность ну до 5%, но я на ненагруженной системе их делаю, а иногда я был удивлен, все три круга одного теста вообще выдавали полностью идентичный результат, цифра в цифру =), тут странный почти 25% разброс, я думаю что-то в этот момент повлияло на систему, но в общем можно предсказать поведение системы и я для себя делаю выводы что лучше включать компрессию и без заморочек - стандартную lz4 или zstd, это даст хороший результат по копрессии и скорости и при этом минимальный оверхэд, экономить вырубая компрессию я пока что не вижу смысла, как и накручивать что-то типа zstd-5 и выше, или gzip мучать
Полностью согласен. Очень много экспериментировал с zstd, не только в zfs, сжимал разные данные, пробовал даже словарь строить, вывод сделал, что не стоит заморачиваться, стандартный уровень сжатия - золотая середина.
Владимир
Норм тесты, в принципе подтверждают мои личные выводы, zstd +-= lz4, всякие около zstd варианты, типа zstd-4|5 или zstd-fast тоже находятся около стандартного zstd, все что плотнее сжимает типа zstd-15 сразу же дает снижение скорости и нагрузку на ЦП, остальное в пределах погрешности. Единственное, что странные показатели теста на запись, там zstd дал 6 cек, lz4 9 сек, а ON 7сек, при этом on включает дефолтную компрессию lz4, у меня результаты были всегда равны, что-то повлияло на тест видать, раз результат почти на 25% изменился, ну или я что-то не знаю про дефолтный режим ON.
ты всё верно говоришь, я просто незнаю как мерять точнее, есть некое непостоянство
Autumn
ты всё верно говоришь, я просто незнаю как мерять точнее, есть некое непостоянство
у меня так же, но я не парюсь, смотрю среднее по палате
Вадим «Дым» Илларионов ☭
ну там мизерная разница как я вижу, как раз говорит о том что ztsd по уморчанию и включает 3 уровень, а так да, на запись чутка "поплыло"
В мане так и написано: умолчальное сжатие — троечка.
Ivan
/report
Михаил
/report
Δαρθ
чото мне кажется что для сжатия главное большой блок. с блоком 16к особо не посжимешь а с мегабайтом уже можно развернуться
Andrew
/report
Δαρθ
Пролил с одного хоста на другой несколько терабайт через zfs send/recv, в двух датасетах по 5-10 файлов битых оказалось (чтение файла даёт io error, zpool status -v их же репортит). Приёмный пул -- из 1 диска (бекап).
1. предполагая что ошибка чисто софтовая (т.е. диск не глючит), возможно ли как-то пофиксить без перелива заново всего датасета?
2. возможны ли такие глюки из-за того что прерывалась заливка (с механизмом resume tokenов)? Один раз пришлось даже руками прибить процесс zfs recv
Andrey
Я бы попробовал так:
- на источнике скопровал бы эти файлы куда-нибудь
- заново скопировал переписал файлы на датасет
- сделал снапшот
- переслал инкремент
Δαρθ
Я бы попробовал так:
- на источнике скопровал бы эти файлы куда-нибудь
- заново скопировал переписал файлы на датасет
- сделал снапшот
- переслал инкремент
А, типа инкремент относительно битого снапшота на приёмнике?
Δαρθ
И чтоб именно эти файлы гарантированно перезаписались
Δαρθ
прикольный способ, спасибо. поимею в виду.
George
Пролил с одного хоста на другой несколько терабайт через zfs send/recv, в двух датасетах по 5-10 файлов битых оказалось (чтение файла даёт io error, zpool status -v их же репортит). Приёмный пул -- из 1 диска (бекап).
1. предполагая что ошибка чисто софтовая (т.е. диск не глючит), возможно ли как-то пофиксить без перелива заново всего датасета?
2. возможны ли такие глюки из-за того что прерывалась заливка (с механизмом resume tokenов)? Один раз пришлось даже руками прибить процесс zfs recv
можно посмотреть на https://github.com/openzfs/zfs/pull/9372
George
плюс если не raidz, и побита только дата, то теоретически можно через zdb вытащить битые блоки в сыром виде с источника и руками перезаписать на проблемном пуле
George
но это геморно и без гарантии
Δαρθ
можно посмотреть на https://github.com/openzfs/zfs/pull/9372
прикольно! с какой версии это замержили?
Δαρθ
плюс если не raidz, и побита только дата, то теоретически можно через zdb вытащить битые блоки в сыром виде с источника и руками перезаписать на проблемном пуле
источник в мирроре, приемник - диск в усб-коробке (которая видимо и причина побития)
Sergio
/report
Владимир
/report
Александр
/report
ALLEX
/report
Free
Приветствую сообщество.
Дали мне ссылку на эту группу как на последнюю надежду спасти 100ТБ данных.
Надеюсь на вашу помощь 🙏
Vladislav
Free
Приобрел сервер с нодами Storj (это и есть основная ценность).
Обнаружил, что виртуальное устройство logs фактически не работает из-за ошибок, вот последнее рабочее состояние:
root@storg2:~# zpool status
pool: my
state: DEGRADED
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A
scan: resilvered 3.34M in 00:00:06 with 0 errors on Thu Sep 7 01:05:34 2023
config:
NAME STATE READ WRITE CKSUM
my DEGRADED 0 0 0
raidz2-0 ONLINE 0 0 0
ata-WUH721816ALE6L4_2BG23XME ONLINE 0 0 0
ata-WUH721816ALE6L4_2BGTN6DR ONLINE 0 0 0
ata-WUH721816ALE6L4_2BGTZ02R ONLINE 0 0 0
ata-WUH721816ALE6L4_2BH43TRD ONLINE 0 0 0
ata-WUH721816ALE6L4_2BHT1W1N ONLINE 0 0 0
ata-WUH721816ALE6L4_2CG6Y0XN ONLINE 0 0 0
ata-WUH721816ALE6L4_2CG71H5N ONLINE 0 0 0
ata-WUH721816ALE6L4_2CGDDE4P ONLINE 0 0 0
ata-WUH721816ALE6L4_2CH7XYYN ONLINE 0 0 0
ata-WUH721816ALE6L4_2CHE5N8N ONLINE 0 0 0
ata-WUH721816ALE6L4_2CJ39NRJ ONLINE 0 0 0
ata-WUH721816ALE6L4_2CJ9REHJ ONLINE 0 0 0
ata-WUH721816ALE6L4_2CJE6N5J ONLINE 0 0 0
ata-WUH721816ALE6L4_3WGXB0NL ONLINE 0 0 0
ata-WUH721816ALE6L4_3WGXPW8J ONLINE 0 0 0
ata-WUH721816ALE6L4_3WHPKZGP ONLINE 0 0 0
ata-WUH721816ALE6L4_3WJZRWMJ ONLINE 0 0 0
logs
mirror-1 UNAVAIL 0 8.03K 0 insufficient replicas
ata-Q3DT-128GMCY_2022061700361 FAULTED 3 0 0 too many errors
ata-Q3DT-128GMCY_2022061700455 FAULTED 6 8.03K 0 too many errors
cache
ata-INTEL_SSDSC2BB480G6_PHWA627000JA480FGN ONLINE 0 0 0
ata-INTEL_SSDSC2BB480G6_PHWA627002FV480FGN ONLINE 0 0 0
errors: 4265 data errors, use '-v' for a list
Ivan
чиа не проще заново сгенерить ?
Free
чиа не проще заново сгенерить ?
Это не Чиа, это Стордж.
Там очень долгий процесс выращивания нод
Free
Для Сторджа старшие товарищи посоветовали не восстанавливать logs, а вообще его убрать.
Сделал удаление командой
zpool remove my mirror-1
Free
Сервер надолго призадумался.
И вот тут - как в кино - у нас в деревне выключился свет 🙈
Free
После включения и перезагрузки :
root@storg2:~# zpool status
no pools available
Free
Попытка импорта:
root@storg2:~# zpool import
pool: my
id: 18386072088339895358
state: UNAVAIL
status: One or more devices are missing from the system.
action: The pool cannot be imported. Attach the missing
devices and try again.
see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-6X
config:
my UNAVAIL missing device
raidz2-0 ONLINE
ata-WUH721816ALE6L4_2BG23XME ONLINE
ata-WUH721816ALE6L4_2BGTN6DR ONLINE
ata-WUH721816ALE6L4_2BGTZ02R ONLINE
ata-WUH721816ALE6L4_2BH43TRD ONLINE
ata-WUH721816ALE6L4_2BHT1W1N ONLINE
ata-WUH721816ALE6L4_2CG6Y0XN ONLINE
ata-WUH721816ALE6L4_2CG71H5N ONLINE
ata-WUH721816ALE6L4_2CGDDE4P ONLINE
ata-WUH721816ALE6L4_2CH7XYYN ONLINE
ata-WUH721816ALE6L4_2CHE5N8N ONLINE
ata-WUH721816ALE6L4_2CJ39NRJ ONLINE
ata-WUH721816ALE6L4_2CJ9REHJ ONLINE
ata-WUH721816ALE6L4_2CJE6N5J ONLINE
ata-WUH721816ALE6L4_3WGXB0NL ONLINE
ata-WUH721816ALE6L4_3WGXPW8J ONLINE
ata-WUH721816ALE6L4_3WHPKZGP ONLINE
ata-WUH721816ALE6L4_3WJZRWMJ ONLINE
logs
mirror-1 UNAVAIL insufficient replicas
ata-Q3DT-128GMCY_2022061700361 UNAVAIL
ata-Q3DT-128GMCY_2022061700455 UNAVAIL
Additional devices are known to be part of this pool, though their
exact configuration cannot be determined.
root@storg2:~# zpool import my
The devices below are missing or corrupted, use '-m' to import the pool anyway:
mirror-1 [log]
ata-Q3DT-128GMCY_2022061700361
ata-Q3DT-128GMCY_2022061700455
cannot import 'my': one or more devices is currently unavailable
Free
То есть logs уцелели, а кэш исчез
Vladislav
А Вы хороши
Vladislav
Логи нельзя удалять из пула raidz
Top-level vdevs can only be removed if the primary pool storage does not contain a top-level raidz vdev
И плюс
ZFS had a bug once where a pool can corrupt (dead as a dodo) after removing a log device.
Free
Логи нельзя удалять из пула raidz
Top-level vdevs can only be removed if the primary pool storage does not contain a top-level raidz vdev
И плюс
ZFS had a bug once where a pool can corrupt (dead as a dodo) after removing a log device.
Вот кстати эту статью я видел.
Но там ведь написано, что это РАНЬШЕ БЫЛ БАГ, и я думал, что сейчас он исправлен
Vladislav
Вот кстати эту статью я видел.
Но там ведь написано, что это РАНЬШЕ БЫЛ БАГ, и я думал, что сейчас он исправлен
А Вы проверили какая у Вас версия?
Алексей
Vladislav
я лично удалял из raidz2
Логи?
https://openzfs.github.io/openzfs-docs/man/master/8/zpool-remove.8.html
Алексей
даже в хистори пула осталось
Vladislav
Надо будет проверить, потому что на моей памяти ни у кого не получалось
Vladislav
Тут был уже товарищ, который пытался
Vladislav
Ему просто фейлилась команда
Алексей
вот спешл удалить нельзя и это был я
Алексей
а лог удаляется
Vladislav
Окей, ещё 7 ссылок форумов показали, что неправ
Free
Таки есть надежда 🤞?
Free
Вот там про опцию -m в выводе написано.
Применять, или есть другие мысли?
Ivan
Таки есть надежда 🤞?
лог терять нельзя, если выключили сервер с логом, а включили без лога.
но там вроде часть транзакций теряется только.
Алексей
лог терять нельзя, если выключили сервер с логом, а включили без лога.
но там вроде часть транзакций теряется только.
лог уже давно полностью развалился