Экспортер - да, кажется, единственный, кто развивается. А дашборды есть не под пятую графану?

В telegraf еще есть

Спасибо, за копию документации, кэп)

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

окей, опустим слово приколюхи. Вот пишу я на том файл размером в 1024Мб при стандартном блоксайзе. Мне реф покажет 1024 Мб, или больше, или меньше? Учтёт ли он мету?

Например, самое явное отличие: USED - СО ВСЕМИ ДЕТЬМИ. REFER - собственные данные: NAME USED AVAIL REFER MOUNTPOINT s01 10.4T 7.66T 104K /s01 s01/125 2.73T 7.66T 2.73T /s01/125 s01/217 2.02T 7.66T 2.02T /s01/217

Например, самое явное отличие: USED - СО ВСЕМИ ДЕТЬМИ. REFER - собственные данные: NAME USED AVAIL REFER MOUNTPOINT s01 10.4T 7.66T 104K /s01 s01/125 2.73T 7.66T 2.73T /s01/125 s01/217 2.02T 7.66T 2.02T /s01/217

спасибо)

Анонс - для своих нужд собрал ubuntu cloud image с root-on-zfs (поддерживается и uefi и legacy загрузка) https://github.com/infraguys/gci_ubuntu_zfs (т.е. этот имадж можно использовать как базовый для VMок в 99% облаков, где есть cloud init) пока в бета-режиме, буду рад любому фидбеку! Важный момент - я специально ставил целью, чтобы это был на 99% апстримный ubuntu cloud image, НО с рутом на zfs (в основном я подменил ФС, и всё), так что риск свёл к минимуму насколько возможно. Образ больше оригинального всего на 150МБ! Пример нарезки на датасеты: # zfs list NAME USED AVAIL REFER MOUNTPOINT rpool 1.06G 7.41G 24K / rpool/ROOT 931M 7.41G 24K none rpool/ROOT/ubuntu 931M 7.41G 931M / rpool/home 63.5K 7.41G 33K /home rpool/home/root 30.5K 7.41G 30.5K /root rpool/srv 24K 7.41G 24K /srv rpool/tmp 96K 7.41G 96K /tmp rpool/var 157M 7.41G 660K /var rpool/var/cache 72.4M 7.41G 72.4M /var/cache rpool/var/lib 82.7M 7.41G 82.7M /var/lib rpool/var/lib/docker 24K 7.41G 24K /var/lib/docker rpool/var/lib/nfs 24K 7.41G 24K /var/lib/nfs rpool/var/log 994K 7.41G 994K /var/log rpool/var/mail 24K 7.41G 24K /var/mail rpool/var/snap 24K 7.41G 24K /var/snap rpool/var/spool 25K 7.41G 25K /var/spool rpool/var/tmp 36K 7.41G 36K /var/tmp Планирую регулярно собирать более свежие имаджи (да и по запросу можно), т.к. там всё автоматизировано на github actions, можете и в форке пересобирать при желании "по тегу".

Анонс - для своих нужд собрал ubuntu cloud image с root-on-zfs (поддерживается и uefi и legacy загрузка) https://github.com/infraguys/gci_ubuntu_zfs (т.е. этот имадж можно использовать как базовый для VMок в 99% облаков, где есть cloud init) пока в бета-режиме, буду рад любому фидбеку! Важный момент - я специально ставил целью, чтобы это был на 99% апстримный ubuntu cloud image, НО с рутом на zfs (в основном я подменил ФС, и всё), так что риск свёл к минимуму насколько возможно. Образ больше оригинального всего на 150МБ! Пример нарезки на датасеты: # zfs list NAME USED AVAIL REFER MOUNTPOINT rpool 1.06G 7.41G 24K / rpool/ROOT 931M 7.41G 24K none rpool/ROOT/ubuntu 931M 7.41G 931M / rpool/home 63.5K 7.41G 33K /home rpool/home/root 30.5K 7.41G 30.5K /root rpool/srv 24K 7.41G 24K /srv rpool/tmp 96K 7.41G 96K /tmp rpool/var 157M 7.41G 660K /var rpool/var/cache 72.4M 7.41G 72.4M /var/cache rpool/var/lib 82.7M 7.41G 82.7M /var/lib rpool/var/lib/docker 24K 7.41G 24K /var/lib/docker rpool/var/lib/nfs 24K 7.41G 24K /var/lib/nfs rpool/var/log 994K 7.41G 994K /var/log rpool/var/mail 24K 7.41G 24K /var/mail rpool/var/snap 24K 7.41G 24K /var/snap rpool/var/spool 25K 7.41G 25K /var/spool rpool/var/tmp 36K 7.41G 36K /var/tmp Планирую регулярно собирать более свежие имаджи (да и по запросу можно), т.к. там всё автоматизировано на github actions, можете и в форке пересобирать при желании "по тегу".

огонь, спасибо)), мне точно пригодится☺️

Анонс - для своих нужд собрал ubuntu cloud image с root-on-zfs (поддерживается и uefi и legacy загрузка) https://github.com/infraguys/gci_ubuntu_zfs (т.е. этот имадж можно использовать как базовый для VMок в 99% облаков, где есть cloud init) пока в бета-режиме, буду рад любому фидбеку! Важный момент - я специально ставил целью, чтобы это был на 99% апстримный ubuntu cloud image, НО с рутом на zfs (в основном я подменил ФС, и всё), так что риск свёл к минимуму насколько возможно. Образ больше оригинального всего на 150МБ! Пример нарезки на датасеты: # zfs list NAME USED AVAIL REFER MOUNTPOINT rpool 1.06G 7.41G 24K / rpool/ROOT 931M 7.41G 24K none rpool/ROOT/ubuntu 931M 7.41G 931M / rpool/home 63.5K 7.41G 33K /home rpool/home/root 30.5K 7.41G 30.5K /root rpool/srv 24K 7.41G 24K /srv rpool/tmp 96K 7.41G 96K /tmp rpool/var 157M 7.41G 660K /var rpool/var/cache 72.4M 7.41G 72.4M /var/cache rpool/var/lib 82.7M 7.41G 82.7M /var/lib rpool/var/lib/docker 24K 7.41G 24K /var/lib/docker rpool/var/lib/nfs 24K 7.41G 24K /var/lib/nfs rpool/var/log 994K 7.41G 994K /var/log rpool/var/mail 24K 7.41G 24K /var/mail rpool/var/snap 24K 7.41G 24K /var/snap rpool/var/spool 25K 7.41G 25K /var/spool rpool/var/tmp 36K 7.41G 36K /var/tmp Планирую регулярно собирать более свежие имаджи (да и по запросу можно), т.к. там всё автоматизировано на github actions, можете и в форке пересобирать при желании "по тегу".

А зачем? Без негатива, реально интересно

А зачем? Без негатива, реально интересно

вообще кейсов несколько - сжатие позволяет сэкономить на объёме вольюмов=деньги (видел даже у людей кейсы когда они на aws покупают локальные nvme и юзают поверх zfs чтобы база влезла, т.к. nvme большего размера тупо не давали) - если у вас уже многое на zfs - сильно проще цикл offsite-бекапов через снапшоты - я ещё планирую использовать его не только для облаков, хочу добиться чтобы из него можно было и bare metal легко загрузить (делаем один инфровый проект в опенсорсе, там хотим как основу заюзать) - в мыслях ещё нативное шифрование включить, и при старте вм по ssh ждать пароль, для особо переживающих в общем облегчалка для тех, кому нужен zfs

Т.е. основной кейс - сжатие?

Имеются цифры по занимаемому пространству рута со сжатием на зфс и без него? Сколько выигрываем?

Кажется, что основной кейс - использование сервисов зфс в облачных вм. И это круто. Главное, чтобы инфровая подложка под дисками была надежной.

Кажется, что основной кейс - использование сервисов зфс в облачных вм. И это круто. Главное, чтобы инфровая подложка под дисками была надежной.

Да вродь про сжатие и бэкапы пишет человек

Да вродь про сжатие и бэкапы пишет человек

я основные примеры кейсов назвал, но верно подметили - банально удобнее эксплуатация, если итак многое на zfs делаешь

Тот же арк с его умными кешами чего стоит

я основные примеры кейсов назвал, но верно подметили - банально удобнее эксплуатация, если итак многое на zfs делаешь

Мне кажется, когда мы эксплуатируем немалое количество сервисов, большую часть вещей делает автоматика, ей будто бы удобство не особо важно

Имеются цифры по занимаемому пространству рута со сжатием на зфс и без него? Сколько выигрываем?

смотря что запишете, но я вам могу пример с локальной фс ноута дать # zfs get compressratio,used,logicalused rpool/ROOT NAME PROPERTY VALUE SOURCE rpool/ROOT compressratio 2.03x - rpool/ROOT used 33.4G - rpool/ROOT logicalused 65.0G - и это без /var никто не мешает, конечно, просто ещё один вольюм создать, но если хочется удобства - зачем себе отказывать

Я вот такую понимаю логику - мы используем зфс вот здесь, нам нравится, хотим, что везде был зфс

смотря что запишете, но я вам могу пример с локальной фс ноута дать # zfs get compressratio,used,logicalused rpool/ROOT NAME PROPERTY VALUE SOURCE rpool/ROOT compressratio 2.03x - rpool/ROOT used 33.4G - rpool/ROOT logicalused 65.0G - и это без /var никто не мешает, конечно, просто ещё один вольюм создать, но если хочется удобства - зачем себе отказывать

lz4?

lz4?

ага

и дефолтный рекордсайз

а сколько дефолт? 1м?

а как оно логи жмёт, ням

а сколько дефолт? 1м?

128k

а в бтрфс только lzo? lz4 нема же?

а в бтрфс только lzo? lz4 нема же?

в бутере есть zstd, но нет lz4

а в zfs есть оба, но по дефолту lz4 т.к. его на 90% кейсов просто не замечаешь по перфу

ну lz4 налету хорошо умеет просто, это бесспорно

lzo тоже прикольный, но от старости сдохнет скоро

Анонс - для своих нужд собрал ubuntu cloud image с root-on-zfs (поддерживается и uefi и legacy загрузка) https://github.com/infraguys/gci_ubuntu_zfs (т.е. этот имадж можно использовать как базовый для VMок в 99% облаков, где есть cloud init) пока в бета-режиме, буду рад любому фидбеку! Важный момент - я специально ставил целью, чтобы это был на 99% апстримный ubuntu cloud image, НО с рутом на zfs (в основном я подменил ФС, и всё), так что риск свёл к минимуму насколько возможно. Образ больше оригинального всего на 150МБ! Пример нарезки на датасеты: # zfs list NAME USED AVAIL REFER MOUNTPOINT rpool 1.06G 7.41G 24K / rpool/ROOT 931M 7.41G 24K none rpool/ROOT/ubuntu 931M 7.41G 931M / rpool/home 63.5K 7.41G 33K /home rpool/home/root 30.5K 7.41G 30.5K /root rpool/srv 24K 7.41G 24K /srv rpool/tmp 96K 7.41G 96K /tmp rpool/var 157M 7.41G 660K /var rpool/var/cache 72.4M 7.41G 72.4M /var/cache rpool/var/lib 82.7M 7.41G 82.7M /var/lib rpool/var/lib/docker 24K 7.41G 24K /var/lib/docker rpool/var/lib/nfs 24K 7.41G 24K /var/lib/nfs rpool/var/log 994K 7.41G 994K /var/log rpool/var/mail 24K 7.41G 24K /var/mail rpool/var/snap 24K 7.41G 24K /var/snap rpool/var/spool 25K 7.41G 25K /var/spool rpool/var/tmp 36K 7.41G 36K /var/tmp Планирую регулярно собирать более свежие имаджи (да и по запросу можно), т.к. там всё автоматизировано на github actions, можете и в форке пересобирать при желании "по тегу".

вот кстати с этой же вмки прям в облаке (т.е. со старта примерно x2 экономим, на логах будет до х5) root@zfs5-std2-1-1-10gb:~# zfs get compressratio,used,logicalused NAME PROPERTY VALUE SOURCE rpool compressratio 2.11x - rpool used 1.06G - rpool logicalused 2.22G -

Тот же арк с его умными кешами чего стоит

ИМХО, но арк на ВМ в облаке тема такая себе, он оперативки сожрёт больше, чем от него будет выхлоп

вообще кейсов несколько - сжатие позволяет сэкономить на объёме вольюмов=деньги (видел даже у людей кейсы когда они на aws покупают локальные nvme и юзают поверх zfs чтобы база влезла, т.к. nvme большего размера тупо не давали) - если у вас уже многое на zfs - сильно проще цикл offsite-бекапов через снапшоты - я ещё планирую использовать его не только для облаков, хочу добиться чтобы из него можно было и bare metal легко загрузить (делаем один инфровый проект в опенсорсе, там хотим как основу заюзать) - в мыслях ещё нативное шифрование включить, и при старте вм по ssh ждать пароль, для особо переживающих в общем облегчалка для тех, кому нужен zfs

Расскажите подробнее: Бэкапим в другой датасет или снапшот>файл?

Просто снапшоты сейчас вродь везде есть, а где нет - лвм просто натягивают

ИМХО, но арк на ВМ в облаке тема такая себе, он оперативки сожрёт больше, чем от него будет выхлоп

вот кстати сейчас немного в новом свете эта тема играет, aws для файловых шар zfs юзают, slog локальный а vdevs прямо в s3 пишут да и на сетевом сторадже локальный кеш тоже играет очень приятно

Расскажите подробнее: Бэкапим в другой датасет или снапшот>файл?

вы можете снапшоты _инкрементально_ передавать куда хотите, например по ssh

и с zfs у вас из коробки offsite-backup инкрементальный можно легко строить, стоимость снапшотов по перфу уже уплачена, можно хранить хоть за каждый час или даже минуты если дифф небольшой

А у хостеров снапшоты на их сторадже, под вм, дорогие нынче?

А у хостеров снапшоты на их сторадже, под вм, дорогие нынче?

зависит от реализации, тот же lvm если thick то просаживается не хило пока снап есть. А thin lvm по перфу сильно медленнее обычного, не помню правда насколько, давно не смотрел

зависит от реализации, тот же lvm если thick то просаживается не хило пока снап есть. А thin lvm по перфу сильно медленнее обычного, не помню правда насколько, давно не смотрел

Оно вродь сильно зависит, на что именно мы lvm натягиваем, если на 1 девайс - там вродь не страшно всё

Оно вродь сильно зависит, на что именно мы lvm натягиваем, если на 1 девайс - там вродь не страшно всё

не в дисках дело, а в механизме снапшота, там же когда снап создан запись в диск сначала скопирует данные для снапа а потом запишет уже данные только т.е. thick lvm когда снапов нет - очень эффективно маппинг строит на блоки, а когда снап есть - платит на записи двойную цену чтобы этот маппинг сохранить

а в CoW фсках маппинг всегда дороже, зато деградации такой на снапах нет т.к. "уже уплочено"

вот кстати с этой же вмки прям в облаке (т.е. со старта примерно x2 экономим, на логах будет до х5) root@zfs5-std2-1-1-10gb:~# zfs get compressratio,used,logicalused NAME PROPERTY VALUE SOURCE rpool compressratio 2.11x - rpool used 1.06G - rpool logicalused 2.22G -

У меня логи даже отдельным датасетом, чтобы максимально показательно было) root@cloud:~# zfs get compressratio,used,logicalused zp0/ubuntu zp0/ubuntu/log NAME PROPERTY VALUE SOURCE zp0/ubuntu compressratio 1.71x - zp0/ubuntu used 3.02G - zp0/ubuntu logicalused 4.57G - zp0/ubuntu/log compressratio 6.74x - zp0/ubuntu/log used 140M - zp0/ubuntu/log logicalused 917M -

У меня логи даже отдельным датасетом, чтобы максимально показательно было) root@cloud:~# zfs get compressratio,used,logicalused zp0/ubuntu zp0/ubuntu/log NAME PROPERTY VALUE SOURCE zp0/ubuntu compressratio 1.71x - zp0/ubuntu used 3.02G - zp0/ubuntu logicalused 4.57G - zp0/ubuntu/log compressratio 6.74x - zp0/ubuntu/log used 140M - zp0/ubuntu/log logicalused 917M -

упаковка гзипом отротированных логов отключена ?

упаковка гзипом отротированных логов отключена ?

Да

У меня простой вопрос, а сколько бы сэкономил гзип?

У меня простой вопрос, а сколько бы сэкономил гзип?

Цифры уже не помню, но незначительно меньше. К тому же gzip ест больше ЦП, в разы. Это особенно заметно на больших логах, на облачной ВМ с одним ядром сервер раньше выпадал на время из работы, т.к. единственное ядро было загружено на 100% gzip'ом при ротации логов. А при использовании zfs экономия места постоянная и нагрузка на ЦП равномерно размазана. К слову, по поводу постоянной экономии места. Была на одной работе ВМ (под софт компании) с большим количеством ядер, но 30Гб места на диске. Коллеги иногда включали дебаг режим и забывали отключить, в итоге 20Гиг съедало за пару дней. А логи не удобно было разбивать по размеру, нужны были по месяцам. После того, как уговорил запулить zfs под логи, мы забыли об этой проблеме. Там сжатие получалось что-то около 11-12х

Цифры уже не помню, но незначительно меньше. К тому же gzip ест больше ЦП, в разы. Это особенно заметно на больших логах, на облачной ВМ с одним ядром сервер раньше выпадал на время из работы, т.к. единственное ядро было загружено на 100% gzip'ом при ротации логов. А при использовании zfs экономия места постоянная и нагрузка на ЦП равномерно размазана. К слову, по поводу постоянной экономии места. Была на одной работе ВМ (под софт компании) с большим количеством ядер, но 30Гб места на диске. Коллеги иногда включали дебаг режим и забывали отключить, в итоге 20Гиг съедало за пару дней. А логи не удобно было разбивать по размеру, нужны были по месяцам. После того, как уговорил запулить zfs под логи, мы забыли об этой проблеме. Там сжатие получалось что-то около 11-12х

Когда административную проблему решают техническим образом это конечно забавно

Когда административную проблему решают техническим образом это конечно забавно

Это лишь пример. То вообще была "веселая" компания))

вот кстати сейчас немного в новом свете эта тема играет, aws для файловых шар zfs юзают, slog локальный а vdevs прямо в s3 пишут да и на сетевом сторадже локальный кеш тоже играет очень приятно

Когда это касается их инфры где память исчисляется террабайтами - да, но сомнительное удовольствие покупать ВМ не на 8ГБ, а на 16-32ГБ потому что ZFS

добрый день, коллеги. Никто не в курсе, почему в zpool_influxdb -n | grep vdev не отображаются устройства, которые находятся в ARC L2 cache?

версия zfs 2.1.x, 2.2.x debian 11, 12

Отображаются vdevs которые находятся в пуле и в ZIL log

Доброго дня. Подскажите, пожалуйста, с чего начать. Есть желание развернуть сервер samba на debian с zfs. Zfs интересует из-за сжатия и снапшотов. В основном хранится много офисных файлов. Может есть мануал с основными моментами для smb? Пробовал собрать из исходников по мануалу zfs, не смог добиться возможности предоставления прав к папкам.

Доброго дня. Подскажите, пожалуйста, с чего начать. Есть желание развернуть сервер samba на debian с zfs. Zfs интересует из-за сжатия и снапшотов. В основном хранится много офисных файлов. Может есть мануал с основными моментами для smb? Пробовал собрать из исходников по мануалу zfs, не смог добиться возможности предоставления прав к папкам.

Не хотите truenas заюзать , там уже этот кейс решили за вас ?

Нужно посмотреть. Спасибо, поизучаю.

Смотрите прикол: zpool list -v NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT backuppool 5.44T 2.47T 2.97T - - 0% 45% 1.00x ONLINE - sda 1.82T 828G 1.00T - - 0% 44.6% - ONLINE sdb 1.82T 843G 1013G - - 0% 45.4% - ONLINE sdc 1.82T 859G 997G - - 0% 46.3% - ONLINE productionz 6.98T 2.24T 4.74T - - 45% 32% 1.00x ONLINE - raidz1-0 6.98T 2.24T 4.74T - - 45% 32.1% - ONLINE sdi 1.82T - - - - - - - ONLINE sdh 1.75T - - - - - - - ONLINE sdg 1.75T - - - - - - - ONLINE sdd 1.82T - - - - - - - ONLINE

А места нет.

И что делать? wtf?

zdb надо показать нет ?

Сейчас. Он считает

Traversing all blocks ... 2.24T completed (32426MB/s) estimated time remaining: 0hr 00min 00sec bp count: 174497041 ganged count: 0 bp logical: 2949584780288 avg: 16903 bp physical: 1775121305088 avg: 10172 compression: 1.66 bp allocated: 2462719176704 avg: 14113 compression: 1.20 bp deduped: 0 ref>1: 0 deduplication: 1.00 bp cloned: 0 count: 0 Normal class: 2462693540864 used: 32.14% Embedded log class 1024 used: 0.00% additional, non-pointer bps of type 0: 4427363 number of (compressed) bytes: number of bps 17: 153 * 18: 14 * 19: 15 * 20: 21 * 21: 26 * 22: 12 * 23: 31 * 24: 185 * 25: 47 * 26: 65 * 27: 87 * 28: 152 * 29: 1846 * 30: 173 * 31: 83 * 32: 23 * 33: 60 * 34: 39 * 35: 41 * 36: 34 * 37: 60 * 38: 85 * 39: 23 * 40: 90 * 41: 163 * 42: 78 * 43: 64 * 44: 120 * 45: 167 * 46: 95 * 47: 112 * 48: 133 * 49: 527 * 50: 392 * 51: 305 * 52: 491 * 53: 394 * 54: 324 * 55: 462 * 56: 364 * 57: 739 * 58: 559 * 59: 409 * 60: 169 * 61: 162 * 62: 255 * 63: 169 * 64: 229 * 65: 181 * 66: 179 * 67: 165 * 68: 359 * 69: 210 * 70: 208 * 71: 222 * 72: 219 * 73: 432 * 74: 238 * 75: 178 * 76: 185 * 77: 275 * 78: 198 * 79: 4216906 **************************************** 80: 2837 * 81: 4238 * 82: 13560 * 83: 3031 * 84: 1841 * 85: 22495 * 86: 6932 * 87: 4330 * 88: 1626 * 89: 13094 * 90: 7800 * 91: 3912 * 92: 4527 * 93: 3268 * 94: 3408 * 95: 3180 * 96: 2654 * 97: 14000 * 98: 2336 * 99: 2410 * 100: 3171 * 101: 11009 * 102: 12817 *

103: 1935 * 104: 2291 * 105: 2233 * 106: 3494 * 107: 2928 * 108: 4367 * 109: 4781 * 110: 8213 * 111: 10490 * 112: 7753 * Dittoed blocks on same vdev: 259690 Blocks LSIZE PSIZE ASIZE avg comp %Total Type - - - - - - - unallocated 2 32K 4.50K 21K 10.5K 7.11 0.00 object directory 1 128K 1K 6K 6K 128.00 0.00 L1 object array 7 3.50K 3.50K 21K 3K 1.00 0.00 L0 object array 8 132K 4.50K 27K 3.38K 29.22 0.00 object array 1 16K 1.50K 6K 6K 10.67 0.00 packed nvlist - - - - - - - packed nvlist size 7 896K 57.5K 237K 33.9K 15.58 0.00 L1 bpobj 869 109M 9.14M 37.4M 44.1K 11.89 0.00 L0 bpobj 876 110M 9.19M 37.7M 44.0K 11.91 0.00 bpobj - - - - - - - bpobj header - - - - - - - SPA space map header 446 6.97M 670K 3.07M 7.06K 10.65 0.00 L1 SPA space map 7.28K 932M 709M 2.78G 391K 1.31 0.12 L0 SPA space map 7.72K 939M 710M 2.78G 369K 1.32 0.12 SPA space map 3 116K 116K 155K 51.7K 1.00 0.00 ZIL intent log 32 4M 32K 128K 4K 128.00 0.00 L5 DMU dnode 32 4M 32K 128K 4K 128.00 0.00 L4 DMU dnode 32 4M 32K 128K 4K 128.00 0.00 L3 DMU dnode 33 4.12M 34.5K 134K 4.06K 122.43 0.00 L2 DMU dnode 68 8.50M 1.22M 3.39M 51.1K 6.95 0.00 L1 DMU dnode 17.6K 282M 26.2M 84.2M 4.78K 10.75 0.00 L0 DMU dnode 17.8K 307M 27.6M 88.1M 4.94K 11.11 0.00 DMU dnode 35 140K 17.5K 71K 2.03K 8.00 0.00 DMU objset - - - - - - - DSL directory 26 44K 4.50K 21K 827 9.78 0.00 DSL directory child map - - - - - - - DSL dataset snap map - - - - - - - DSL props - - - - - - - DSL dataset - - - - - - - ZFS znode - - - - - - - ZFS V0 ACL 6 768K 20K 58K 9.67K 38.40 0.00 L2 ZFS plain file 19.7K 2.46G 40.8M 131M 6.63K 61.80 0.01 L1 ZFS plain file 721K 71.1G 38.6G 51.7G 73.5K 1.84 2.26 L0 ZFS plain file 741K 73.6G 38.7G 51.9G 71.7K 1.90 2.26 ZFS plain file 419 52.4M 445K 1.69M 4.12K 120.52 0.00 L1 ZFS directory 21.1K 44.0M 10.9M 34.8M 1.65K 4.05 0.00 L0 ZFS directory 21.5K 96.4M 11.3M 36.5M 1.69K 8.53 0.00 ZFS directory 5 2.50K 2.50K 10K 2K 1.00 0.00 ZFS master node 6 28.5K 2K 8K 1.33K 14.25 0.00 ZFS delete queue 15 1.88M 35K 108K 7.20K 54.86 0.00 L3 zvol object 371 46.4M 17.7M 47.4M 131K 2.62 0.00 L2 zvol object 198K 24.8G 7.63G 20.5G 106K 3.25 0.89 L1 zvol object 165M 2.59T 1.57T 2.17T 13.4K 1.65 96.72 L0 zvol object 166M 2.61T 1.58T 2.19T 13.5K 1.66 97.61 zvol object - - - - - - - zvol prop - - - - - - - other uint8[] - - - - - - - other uint64[] - - - - - - - other ZAP - - - - - - - persistent error log

1 128K 1K 6K 6K 128.00 0.00 L1 SPA history 6 768K 65.5K 267K 44.5K 11.73 0.00 L0 SPA history 7 896K 66.5K 273K 39K 13.47 0.00 SPA history - - - - - - - SPA history offsets - - - - - - - Pool properties - - - - - - - DSL permissions - - - - - - - ZFS ACL - - - - - - - ZFS SYSACL - - - - - - - FUID table - - - - - - - FUID table size 1 1.50K 512 3K 3K 3.00 0.00 DSL dataset next clones - - - - - - - scan work queue 15 22.5K 5.50K 22K 1.47K 4.09 0.00 ZFS user/group/project used - - - - - - - ZFS user/group/project quota - - - - - - - snapshot refcount tags - - - - - - - DDT ZAP algorithm - - - - - - - DDT statistics 203 102K 102K 406K 2K 1.00 0.00 System attributes - - - - - - - SA master node 5 7.50K 2.50K 10K 2K 3.00 0.00 SA attr registration 10 160K 20K 60K 6K 8.00 0.00 SA attr layouts - - - - - - - scan translations - - - - - - - deduplicated block - - - - - - - DSL deadlist map - - - - - - - DSL deadlist map hdr 3 2.50K 512 3K 1K 5.00 0.00 DSL dir clones - - - - - - - bpobj subobj - - - - - - - deferred free - - - - - - - dedup ditto 22 2.75M 22K 132K 6K 128.00 0.00 L1 other 70 907K 102K 465K 6.64K 8.94 0.00 L0 other 92 3.64M 124K 597K 6.49K 30.15 0.00 other 32 4M 32K 128K 4K 128.00 0.00 L5 Total 32 4M 32K 128K 4K 128.00 0.00 L4 Total 47 5.88M 67K 236K 5.02K 89.79 0.00 L3 Total 410 51.2M 17.7M 47.6M 119K 2.89 0.00 L2 Total 219K 27.3G 7.67G 20.6G 96.4K 3.56 0.90 L1 Total 166M 2.66T 1.61T 2.22T 13.7K 1.65 99.10 L0 Total 166M 2.68T 1.61T 2.24T 13.8K 1.66 100.00 Total 266K 28.7G 8.42G 23.6G 90.6K 3.41 1.03 Metadata Total Block Size Histogram

block psize lsize asize size Count Size Cum. Count Size Cum. Count Size Cum. 512: 2.68M 1.34G 1.34G 20.0K 9.99M 9.99M 0 0 0 1K: 3.79M 5.08G 6.41G 40.1K 47.8M 57.8M 2.66M 2.66G 2.66G 2K: 19.2M 53.1G 59.5G 35.0K 91.2M 149M 7.49M 18.7G 21.4G 4K: 49.6M 258G 317G 19.5K 104M 253M 44.4M 250G 272G 8K: 17.6M 193G 510G 15.0K 169M 422M 30.3M 299G 571G 16K: 68.7M 1.07T 1.57T 161M 2.52T 2.52T 76.7M 1.61T 2.17T 32K: 355K 15.0G 1.59T 14.5K 675M 2.52T 178K 8.36G 2.18T 64K: 67.7K 6.00G 1.59T 9.39K 848M 2.52T 283K 28.3G 2.20T 128K: 180K 22.5G 1.61T 778K 97.2G 2.62T 204K 33.3G 2.24T 256K: 0 0 1.61T 0 0 2.62T 6.99K 2.74G 2.24T 512K: 0 0 1.61T 0 0 2.62T 0 0 2.24T 1M: 0 0 1.61T 0 0 2.62T 0 0 2.24T 2M: 0 0 1.61T 0 0 2.62T 0 0 2.24T 4M: 0 0 1.61T 0 0 2.62T 0 0 2.24T 8M: 0 0 1.61T 0 0 2.62T 0 0 2.24T 16M: 0 0 1.61T 0 0 2.62T 0 0 2.24T capacity operations bandwidth ---- errors ---- description used avail read write read write read write cksum productionz 2.24T 4.74T 9.07K 0 107M 0 0 0 0 raidz1 2.24T 4.74T 9.07K 0 107M 0 0 0 0 /dev/sdi1 2.37K 0 26.9M 0 0 0 0 /dev/sdh1 2.17K 0 26.6M 0 0 0 0 /dev/sdg1 2.33K 0 26.9M 0 0 0 0

🙂

zpool list показывает сырое пространство zfs list - логическое для raidz очень важно смотреть на логическое, а не сырое. Смотрите туда, плюс смотрите на reservation, емнип если юзаете thick-allocated zvols то можно увидеть именно такое

Иногда мне очень грустно, что у меня нет админа, чтобы заставлять людей или читать как надо выкладывать простыни из вывода команд или удалять их посты как спам, пока они не научатся

Иногда мне очень грустно, что у меня нет админа, чтобы заставлять людей или читать как надо выкладывать простыни из вывода команд или удалять их посты как спам, пока они не научатся

вот бы ещё можно было по рукам линейкой бить.

zpool list показывает сырое пространство zfs list - логическое для raidz очень важно смотреть на логическое, а не сырое. Смотрите туда, плюс смотрите на reservation, емнип если юзаете thick-allocated zvols то можно увидеть именно такое

И что мне делать?

zfs destroy -r productionz/vm-106-disk-0 internal error: cannot destroy snapshots: Номер канала вне диапазона fish: Job 1, 'zfs destroy -r productionz/vm-1…' terminated by signal SIGABRT (Abort) Вот например я удаляю не нужный zvol

zfs destroy -r productionz/vm-106-disk-0 internal error: cannot destroy snapshots: Номер канала вне диапазона fish: Job 1, 'zfs destroy -r productionz/vm-1…' terminated by signal SIGABRT (Abort) Вот например я удаляю не нужный zvol

zfs list -t snapshot

zfs list -t snapshot

ну тут надо подумать....

Удаляю снапшоты.

Что это за хрень? "Номер канала вне диапазона"

dmesg -T

или "где скрипт получали туда и идите"

Мне больше нравится 0 размер снапшотов и дата создания в одну и туже секунду

Что это за хрень? "Номер канала вне диапазона"

Не знаю, поставьте английский язык обратно и проверьте

Что это за хрень? "Номер канала вне диапазона"

гугл и переводчик подскажут https://github.com/openzfs/zfs/issues/9849#issuecomment-575281458 и далее есть примеры как можно обходить, плюс вопрос какая версия zfs стояла, в более свежих были улучшения

При чем тут скрипт? Файловая система гавно. Не может такого происходить в нормальных фс