или я тебя не понял

у пула же нет размера ( в мегабайтах)

у пула же нет размера ( в мегабайтах)

Это как раз и есть размер. 16*16 обжектов. Но когда наполняются данные - обжект пухнут. вот и всё

ШТЭ. в RBD объекты по 4 мегабайта. или это не те объекты ?

и их явно больше чем 256

у меня

у пула же нет размера ( в мегабайтах)

а, да, забыл, при пулах 16*16 не стоит загонять много данных в такой пул. желательно не более 256 гигабайт.

у меня 5 тб суммарно на дисках

ШТЭ. в RBD объекты по 4 мегабайта. или это не те объекты ?

можно больше чем 4 =)

можно больше чем 4 =)

можно. на нахрена ?

210К объектов

можно. на нахрена ?

Память экономить же. тут как в hugepages. Вот нахрена они нужны ? а чтобы таблицу распределения экономить. тут аналогично.

логика ясна.

а тогда почему они по дефолту сделали 4мб ? чо б не гигабайт сделать ?

а тогда почему они по дефолту сделали 4мб ? чо б не гигабайт сделать ?

Памяти много потомучто. мельче блоки - легче ими оперировать. реплицировать 4 мегабайта и гигабайт - есть разница ?

понятно

но всё же я нихрена не понял про pg_num

есть гденибудь нормальное пояснение

?

http://docs.ceph.com/docs/master/rados/operations/placement-groups/ =)

лучше не читал

ну дак. и чот я там не вижу привязки к числу объектов в пуле

вернее как это связано

только насчёт неравномерности заполнения пг объектами

ну дак. и чот я там не вижу привязки к числу объектов в пуле

м собственно в доке и написано Minimizing the number of placement groups saves significant amounts of resources.

никакого там преаллоцирования тож не вижу (на пустом пуле)

ну дак. и чот я там не вижу привязки к числу объектов в пуле

щас найду, сек

у проксмокса так предлагают считать число pg: Total PGs = (# of OSDs * 100) / Replicas Take this result and round up to the nearest Power of 2

никакого там преаллоцирования тож не вижу (на пустом пуле)

переаллоцирование при изменении на лету будет, ибо The Ceph client will calculate which placement group an object should be in. It does this by hashing the object ID and applying an operation based on the number of PGs in the defined pool and the ID of the pool.

нууу. разумеется я это прочитал

кстати у меня вот так:

пипец неравномерно. почему интересно?

а, это суммарно по разным пулам.

не, всё нормально. вполне равномерно

получается, если сделать тупо меньше пг, то в каждой будет больше объектов. чем это плохо ?

получается, если сделать тупо меньше пг, то в каждой будет больше объектов. чем это плохо ?

Тем что если умер OSD и потерял данные - реплицировать нужно весь ПГ, а он огромный

о, точно

у проксмокса так предлагают считать число pg: Total PGs = (# of OSDs * 100) / Replicas Take this result and round up to the nearest Power of 2

это дока ceph http://ceph.com/pgcalc/

Дока рекомендует минимум 128, но у меня и на 16 работает нормально. и памяти жрет заметно меньше.

я писал жу

ну, да ссылка на калькулятор там тоже есть

о, точно

Вот еще https://www.spinics.net/lists/ceph-devel/msg23048.html

osd map 4.6MB - это сколько дисков-то получается?

http://xfs.org/index.php/XFS_FAQ Write barrier support is enabled by default in XFS since kernel version 2.6.17. It is disabled by mounting the filesystem with "nobarrier".

Очевидно же, дока врет :)

у проксмокса так предлагают считать число pg: Total PGs = (# of OSDs * 100) / Replicas Take this result and round up to the nearest Power of 2

pg calc же есть

а, уже ответили)

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

Очевидно же, дока врет :)

Чейджлог видимо тоже.

Чейджлог видимо тоже.

код - самая надежная дока, чейнджлог очень близко к коду. еще есть обсуждения в lkml где с разных сторон подтверждаются отношения между xfs и nobarrier

код - самая надежная дока, чейнджлог очень близко к коду. еще есть обсуждения в lkml где с разных сторон подтверждаются отношения между xfs и nobarrier

Осд буду на 4.9 ядро переводить - посмотрю.

Привет. При попытке сделать снапшот пула получаю ошибку Error EINVAL: pool <..> is in unmanaged snaps mode. rbd-шных снапшотов в пуле не наблюдается. Можно это как-то пофиксить?

Привет. При попытке сделать снапшот пула получаю ошибку Error EINVAL: pool <..> is in unmanaged snaps mode. rbd-шных снапшотов в пуле не наблюдается. Можно это как-то пофиксить?

А как дошли до жизни такой?

А что не так?

А что не так?

гуглится по этой ошибке вот такое письмецо с мутным пронозом https://www.mail-archive.com/ceph-users@lists.ceph.com/msg13930.html Читали?

Да, видела. Но оно от 2014 года... Вдруг уже есть решение, которого я не смогла найти

Да, видела. Но оно от 2014 года... Вдруг уже есть решение, которого я не смогла найти

Но история у вас аналогичное, жил был rados, а потом пул, на котором он был, кто-то отснапшотил?

ШТА?

ШТА?

?

Да, история похожа. В этом пуле уже делались rbd снапшоты

щекотливая история. Данных много у вас?

В районе 500 гигов

От 500 до 1000, если все образы учитывать. Точнее не помню

В районе 500 гигов

Я бы по возможности попытался перенести в другой пул

А это поможет? И я все еще не теряю веры в то, что есть другой вариант, без переносов))

ну, один объект перекинуть и посмотреть

Судя по коду, информация на мониторах не верна

Хотя нет, ошибся

Можно создать новый пул и diff-export import сделать

Кста, кластер про который спрашивает @AnnaSvalova это тот же самый что и у меня.

мне мож сейчас купят 3 ноды под ceph

вас читаешь, тестерам страшно давать становится пространство в нём

короче, течёт кракен как сучка перед случкой

и не понятно в какие именно моменты

Ну так лтс надо ставить, лтс)

Лтс?

Слишком много вариантов

Лтс?

LTS

Long time support

А ты про это