История изменений
Исправление bugfixer, (текущая версия) :
Это не так. ~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 - пофиг, кмк).
В общем - придётся таки походу заныривать в сорсы ядра ещё глубже…
Исправление bugfixer, :
Это не так. ~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, остальное это randomly spread short updates (WAF accounted for). Собственно поэтому agcount в 1k и казался разумным - была надежда что fragmantation будет меньше (хотя на SSD - пофиг, кмк).
В общем - придётся таки походу заныривать в сорсы ядра ещё глубже…
Исходная версия bugfixer, :
Это не так. ~32TB в массиве => должно быть ~32 ag по дефолту.
Расковырял чуть глубже: в старые времена agsize походу была ограничена 4GB, отсюда и «растут ножки» более ранних рекомендаций - «группа на 3GB» (I’m still puzzled почему дефолтам не доверять?). Нынче размер ограничен 1TB. Для 32TB+ volumes mkfs.xfs сваливается в «размер / 1TB» for group size (что понянтно). Что интересно - для volumes меньшего размера (но большего 512GB) agcount «гвоздями прибит» к 32ум, и мне совсем неочевидно почему - цифра с потолка взята, кмк… Typical core count, may be?
В нашем случае будет открыто в каждый конкретный момент времени порядка 1k файлов на запись, будем писать примерно 3TB/day (according to iostat) при заполнении fs примерно 80%, из которых 1.5-2TB это appends, остальное это randomly spread short updates (WAF accounted for). Собственно поэтому agcount в 1k и казался разумным - была надежда что fragmantation будет меньше (хотя на SSD - пофиг, кмк).
В общем - придётся таки походу заныривать в сорсы ядра ещё глубже…