вдруг это давно починили ? или недавно )

вдруг =), но я забил

юзаю zfs без л2арк

на сегодняшний день l2arc может вызывать тормоза ? допустим 128 гигов рамы отдано под arc и для пущей скорости решил на ssd/nvme l2arc сделать. хуже не будет ?

Явных проблем на пустом месте давать не должен при достаточном количестве ОЗУ, но надо учитывать что ОЗУ он использует + это всё таки доп логика в ARC. При явной деградации стоит репортить баг с воспроизведением

в 2.0 он стал к тому же персистентным

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

в 2.0 он стал к тому же персистентным

получаестя если часто ребутать хост, то hit ratio для кэша будет сильно расти ? )

получаестя если часто ребутать хост, то hit ratio для кэша будет сильно расти ? )

зависит от нагрузки)

если кейс позволяет прогреть l2arc, то теоретически да

только бенчить стоит не сразу после ребута, в озу асинхронно подгружается мета об l2arc

из плюсов - arc емнип тоже сбрасывается теперь туда (если память не изменяет). Пока не тестил

из плюсов - arc емнип тоже сбрасывается теперь туда (если память не изменяет). Пока не тестил

перед ребутом ?

перед ребутом ?

угу

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

l2arc_headroom (ulong) How far through the ARC lists to search for L2ARC cacheable content, expressed as a multiplier of l2arc_write_max. ARC persistence across reboots can be achieved with persistent L2ARC by setting this parameter to 0 allowing the full length of ARC lists to be searched for cacheable content. Default value: 2.

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

ну статистика arc, по ней всё и определяется

mru часть как обычно вымываема, mfu относительно стойкий к вымыванию

mru можно для l2arc отключить теперь l2arc_mfuonly (int) Controls whether only MFU metadata and data are cached from ARC into L2ARC. This may be desired to avoid wasting space on L2ARC when reading/writing large amounts of data that are not expected to be accessed more than once. The default is 0, meaning both MRU and MFU data and metadata are cached. When turning off ( 0) this feature some MRU buffers will still be present in ARC and eventually cached on L2ARC. If l2arc_noprefetch is set to 0, some prefetched buffers will be cached to L2ARC, and those might later transition to MRU, in which case the l2arc_mru_asize arcstat will not be 0. Regardless of l2arc_noprefetch, some MFU buffers might be evicted from ARC, accessed later on as prefetches and transition to MRU as prefetches. If accessed again they are counted as MRU and the l2arc_mru_asize arcstat will not be 0. The ARC status of L2ARC buffers when they were first cached in L2ARC can be seen in the l2arc_mru_asize, l2arc_mfu_asize and l2arc_prefetch_asize arcstats when importing the pool or onlining a cache device if persistent L2ARC is enabled. The evicted_l2_eligible_mru arcstat does not take into account if this option is enabled as the information provided by the evicted_l2_eligible_* arcstats can be used to decide if toggling this option is appropriate for the current workload. Use 0 for no (default) and 1 for yes.

всё в доке https://openzfs.github.io/openzfs-docs/man/5/zfs-module-parameters.5.html?highlight=persistent

l2arc хорош чтобы латенси уменьшить чтения, и то не на каждом кейсе поможет

стандартная проблема кешей, в общем то

я бы начисто доку от солярки к zfs on linux не применял бы

Однозначно да, но самое главное в этом гайде - фраза «tuning is evil» с посылом «донт ду до ит, бигбой, ю ноу, тюнин итс э дэвилз той, ежжи»)) Где-то в этом же чате происходила беседа, что тюнинг хорош тем, что пока тюнишь - разбираешься, как работает, а потом уже со знанием дела откатываешь все в дефолт, ибо что-то лучше сообразить, чем разрабы и правда сложно.

стандартная проблема кешей, в общем то

Спасибо за детальное разжевывание, многое ясно. У меня много последовательного чтения длинных блоков, так что, предполагаю, 5 процентов хитов оно вывозит только потому, что файлы относительно больше (20-200гб), на мелочи, предположительно, оно бы в районе 0 висело, хех

У меня при интенсивной записи были тормоза, жёсткие совсем тупые и дико отставали

Ммм... думаю, надо конфигурацию пула и паттерн данных понять. Я пока первый раз с трунасом ковырялся пересобрал пул раз 6 наверное, и каждый раз на одних и тех же данных результаты были удивительно разные, из-за особенностей обхода звол и отдельных дисков при записи.

Спасибо за детальное разжевывание, многое ясно. У меня много последовательного чтения длинных блоков, так что, предполагаю, 5 процентов хитов оно вывозит только потому, что файлы относительно больше (20-200гб), на мелочи, предположительно, оно бы в районе 0 висело, хех

Есть параметр по которому и последовательное чтение начнёт в l2arc попадать, но этот случай имеет смысл только если к этим данным ещё будет не один раз повторный доступ, иначе сильно вымывается l2arc

Есть параметр по которому и последовательное чтение начнёт в l2arc попадать, но этот случай имеет смысл только если к этим данным ещё будет не один раз повторный доступ, иначе сильно вымывается l2arc

Монтаж тяжелого видео, основная работа как раз с текущим набором данных именно в режиме чтения, новые данные раз в день-два-три небольшими порциями до 1 тб

Так что совет годный, ещё раз покорнейше благодарю

Монтаж тяжелого видео, основная работа как раз с текущим набором данных именно в режиме чтения, новые данные раз в день-два-три небольшими порциями до 1 тб

https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#l2arc-noprefetch

вот параметр

Монтаж тяжелого видео, основная работа как раз с текущим набором данных именно в режиме чтения, новые данные раз в день-два-три небольшими порциями до 1 тб

да, как раз ваш случай, видимо

тоже когда-то его использовал для раздачи видео

ВМ, создана на zvol, смотрю через zfs list вижу что диск заполнен на 81 ГБ, если же смотрю изнутри вм то заполнено всего 40, это к zfs относится? или где вообще хвосты искать у этой проблемы?

ВМ, создана на zvol, смотрю через zfs list вижу что диск заполнен на 81 ГБ, если же смотрю изнутри вм то заполнено всего 40, это к zfs относится? или где вообще хвосты искать у этой проблемы?

это нормально

хочешь уменьшить zvol - включи thin provisioning, а внутри вм сделай трим. вм должна быть на virtio scsi диске.

ВМ, создана на zvol, смотрю через zfs list вижу что диск заполнен на 81 ГБ, если же смотрю изнутри вм то заполнено всего 40, это к zfs относится? или где вообще хвосты искать у этой проблемы?

- из vm trim делайте, отпустит не занятое место

- плюс если использовать raidz, то может занимать больше

fstrim -av вот такую команду уже посоветовали, сделал, все то же изменений нету

- плюс если использовать raidz, то может занимать больше

вообще без raid хранилище

fstrim -av вот такую команду уже посоветовали, сделал, все то же изменений нету

если диск virtio scsi, то надо подождать пока zvol прохудится. это не моментальный процесс.

если диск вм sata или ide, то чуда не случится

если диск вм sata или ide, то чуда не случится

кстати да

если диск virtio scsi, то надо подождать пока zvol прохудится. это не моментальный процесс.

да походу оно, спасибо, а как принято разруливать данную ситацию, добавлять trim в cron или какие то еще есть решения?

да походу оно, спасибо, а как принято разруливать данную ситацию, добавлять trim в cron или какие то еще есть решения?

systemctl enable fstrim кажись

это лучше, чем указывать дискард в опциях монтирования фс

https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#l2arc-noprefetch

Супер, читаю и буду смотреть и проверять. Вот все б как вы и в мире давно бы наступил полный пацифизм)

Супер, читаю и буду смотреть и проверять. Вот все б как вы и в мире давно бы наступил полный пацифизм)

Добрый день.

есть зеркальный пул

хочу добавить к нему третий в зеркало

даю

zpool attach spoolDB ata-MTFDDAK256MAY-1AH12ABHA_14300CE7A6F9-part1 /dev/disk/by-id/ata-SAMSUNG_MZ7LN256HCHP-000H1_S1ZPNXAG703906-part1

invalid vdev specification use '-f' to override the following errors:

форсить очень страшно

вроде ж все верно?

а у тебя есть разделы на том диске который ты добавляешь?

или он чистый?

на новый диск сделал так

# sgdisk <healthy bootable device> -R <new device> # sgdisk -G <new device>

т.е. скопировал структуру уже работающих

zpool attach spoolDB ata-MTFDDAK256MAY-1AH12ABHA_14300CE7A6F9-part1 /dev/disk/by-id/ata-SAMSUNG_MZ7LN256HCHP-000H1_S1ZPNXAG703906-part1

Что-то тут не так

форсить очень страшно

я бы искал что не так, оно без форса должно работать

оно?

/dev/disk/by-id/ata-SAMSUNG_MZ7LN256HCHP-000H1_S1ZPNXAG703906-part1 contains a filesystem of type 'ntfs'

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

если диск virtio scsi, то надо подождать пока zvol прохудится. это не моментальный процесс.

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

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

покажи конфиг вм

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

Рискнул, с форсом. Да, оно не шло ибо видело остатки тсарой ФС

покажи конфиг вм

https://pastebin.com/1NV5LaKN этот?

https://pastebin.com/1NV5LaKN этот?

снапшотов нет внутри или снаружи ?

внутри, снаружи все по нулям (у zfs два снепшота, но у них по нулям занятое пространство)

это лучше, чем указывать дискард в опциях монтирования фс

почему ?

почему ?

С одной стороны с дискард падает производительность, но не катастрофически. С другой fstrim.timer запускается раз в две недели, кажется. И вот при нём реально падает производительно на время выполнения. Если надо просто держать в порядке свободное место, то fstrim. А если у вас, например, vdo раздел, то однозначно дискард.

С одной стороны с дискард падает производительность, но не катастрофически. С другой fstrim.timer запускается раз в две недели, кажется. И вот при нём реально падает производительно на время выполнения. Если надо просто держать в порядке свободное место, то fstrim. А если у вас, например, vdo раздел, то однозначно дискард.

что такое vdo раздел ?)

что такое vdo раздел ?)

virtual data optmizer

С одной стороны с дискард падает производительность, но не катастрофически. С другой fstrim.timer запускается раз в две недели, кажется. И вот при нём реально падает производительно на время выполнения. Если надо просто держать в порядке свободное место, то fstrim. А если у вас, например, vdo раздел, то однозначно дискард.

Спасибо!

https://github.com/openzfs/zfs/pull/11823

https://github.com/openzfs/zfs/pull/11823

блин, сначала подумал ооогоо. а потом посмотрел дату

мы ж в xfs чате сегодня)

мы ж в xfs чате сегодня)

расскажите как перестать терять данные при потере питания

расскажите как перестать терять данные при потере питания

данные не терялись. но расскажите, как проверить ФС без отмонтирования?)