xfs: optimal allocation group count

Что-то мне подсказывает я что-то сделал не так. Может случайно анонимам запретил комментировать (не хотел - случайность чес слово, если кто-то из админов может поправить я только рад буду), что-то. Может это какая-то супер секретная know how, не понятно. Ну да ладно. Всех с праздничком если чего! И исполнения всех желаний!

Склоняюсь к 1024

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

Хм, дефолт как то не сильно вяжется с предложением «группа на 4-8Gb» которое регулярно встречаю на форумах. Чем плох большой agcount?

Вот что у редхата написано по этому поводу:

https://access.redhat.com/solutions/2532271

The xfs filesystem chooses the appropriate Allocation Group number depending on the Stripe Width and Stripe unit provided during the filesystem creation. For manually deciding the number of optimum allocation number in an environment where the stripe width and stripe unit are unknown, Select the allocation number such that allocation-groups/CPU-core ratio to be <= 1 . This will minimize CPU contention for XFS per Allocation group locks etc.

Оно на десятках терабайт сваливается в 32. 32 однозначно мало, учитывая MQ и тому подобные новомодные плюшки.

32 однозначно мало

Да и ядер на этой конкретной машинке - 80, после HT…

«группа на 4-8Gb» которое регулярно встречаю на форумах.

Это не так. ~32TB в массиве => должно быть ~32 ag по дефолту. Это вполне нормально при 40 ядрах.

Это не так. ~32TB в массиве => должно быть ~32 по дефолту.

Имеется аргументация сильнее чем «патаму што»? Мне не очевидно, от слова совсем…

Это не так. ~32TB в массиве => должно быть ~32 ag по дефолту.

Расковырял чуть глубже: в старые времена agsize походу была ограничена 4GB, отсюда и «растут ножки» более ранних рекомендаций - «группа на 3GB» (I’m still puzzled почему дефолтам не доверять?). Нынче размер ограничен 1TB. Для 32TB+ volumes mkfs.xfs сваливается в «размер / 1TB» for group count (что понянтно). Что интересно - для volumes меньшего размера (но большего 512GB) agcount «гвоздями прибит» к 32ум, и мне совсем неочевидно почему - цифра с потолка взята, кмк… Typical core count, may be?

В нашем случае будет открыто в каждый конкретный момент времени порядка 1k файлов на запись, будем писать примерно 3TB/day (according to iostat) при заполнении fs примерно 80%, из которых 1.5-2TB это appends ~1kb each, остальное это randomly spread short updates (WAF accounted for). Собственно поэтому agcount в 1k и казался разумным - была надежда что fragmantation будет меньше (хотя на SSD - пофиг, кмк).

В общем - придётся таки походу заныривать в сорсы ядра ещё глубже…