с fio соответственно тоже самое, пока имидж не залит полностью, процентов 10-20 при записи льется в тиер, остальное в основной

а в документации что написано?

в документации по ceph или fio ? по fio где-то видел рекомендацию перезаписывать нулями перед тестом, но раньше с этим не замечал проблем, вернее замечал конечно с thin дисками, но там логика процесса была вполне ясна если речь о ceph, то я пока не нашел или имеется в виду это? RBD with replicated cache and erasure-coded base: This is a common request, but usually does not perform well. Even reasonably skewed workloads still send some small writes to cold objects, and because small writes are not yet supported by the erasure-coded pool, entire (usually 4 MB) objects must be migrated into the cache in order to satisfy a small (often 4 KB) write. Only a handful of users have successfully deployed this configuration, and it only works for them because their data is extremely cold (backups) and they are not in any way sensitive to performance. RBD with replicated cache and base: RBD with a replicated base tier does better than when the base is erasure coded, but it is still highly dependent on the amount of skew in the workload, and very difficult to validate. The user will need to have a good understanding of their workload and will need to tune the cache tiering parameters carefully.

в документации по ceph или fio ? по fio где-то видел рекомендацию перезаписывать нулями перед тестом, но раньше с этим не замечал проблем, вернее замечал конечно с thin дисками, но там логика процесса была вполне ясна если речь о ceph, то я пока не нашел или имеется в виду это? RBD with replicated cache and erasure-coded base: This is a common request, but usually does not perform well. Even reasonably skewed workloads still send some small writes to cold objects, and because small writes are not yet supported by the erasure-coded pool, entire (usually 4 MB) objects must be migrated into the cache in order to satisfy a small (often 4 KB) write. Only a handful of users have successfully deployed this configuration, and it only works for them because their data is extremely cold (backups) and they are not in any way sensitive to performance. RBD with replicated cache and base: RBD with a replicated base tier does better than when the base is erasure coded, but it is still highly dependent on the amount of skew in the workload, and very difficult to validate. The user will need to have a good understanding of their workload and will need to tune the cache tiering parameters carefully.

а вы цеф к чему прикручиваете?

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

просто к фио при параметре ioengine=rbd у меня есть ряд вопросов

и подозрений

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

если так, побыстрому, то у меня разница между ioengine=libaio и rbd раза в 1.5 по иопсам на одном и том же имидже

в пользу libaio

мда

А мне кажется, всё дело в комбинации —sync и —fsync

А мне кажется, всё дело в комбинации —sync и —fsync

Ну расскажи нам

--direct=1

я так и не понял какого болта, но все 4 варианта (по каждому ключу вкл и выкл) дают на libaio на HDD разные результаты. прям совсем разные.

ну и на rbd они тоже влияют

ещё. про заполнение нулями

чтобы зааллокейтить чо-то там на XFS надо синкать в XFS-ном журнале метаданные от XFS. Когда же файл аллоцирован, то доступ к его данным (а цеф, вроде. вобще к ним в режиме O_DIRECT обращается) не требует записывания изменений в журнал

поэтому предварительное прописывание образа перед бенчмарком имеет реальный смысел

ну мож тока mtime + atime. но это отключаемо в опциях монтирования

поэтому предварительное прописывание образа перед бенчмарком имеет реальный смысел

здесь я согласен насчет бенчмарка, но спрашивал я о логике процесса - не могу понять почему 90% записи попадает в холодный пул, а 10% в горячий

интересно как это все будет работать вместе с evict'ом объектов из горячего пула

здесь я согласен насчет бенчмарка, но спрашивал я о логике процесса - не могу понять почему 90% записи попадает в холодный пул, а 10% в горячий

может потому что кеширующий пул кеширует только то что кем-то читается? похоже на маразм.

здесь я согласен насчет бенчмарка, но спрашивал я о логике процесса - не могу понять почему 90% записи попадает в холодный пул, а 10% в горячий

а там этот пул в режиме witeback или write-through?

может потому что кеширующий пул кеширует только то что кем-то читается? похоже на маразм.

да вроде нет, после перезаписи нулями все работает как надо

а там этот пул в режиме witeback или write-through?

writeback

АААА

я вспомнил. видел такое на аппаратном рейде

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

может это?

гм, не знаю

а как соотносится с нормальной работой "размеченного" пула?

кстати, а общие иопсы пула у вас какие получаются, сравнимы с суммой иопсов всех винтов? Или какой примерно коэфф?

у меня коэффициент какой-то очень тухлый получается, но и винты вообще-то половина из помойки

А мне кажется, всё дело в комбинации —sync и —fsync

Тебе ссд приехали? Тест делал?

Тебе ссд приехали? Тест делал?

приехал. купили переходник с M2 на PCIExpress. включили. дымок. сдали по гарантии

прям реально дымок. выгорела дорожка

Пиздец

прям реально дымок. выгорела дорожка

У меня так почти в 2002 винт сдыхал. Чото щелкнуло и сервант с nt4 начал конкретно так лагать. Когда разобрал - на контроллере винта часть микросхемы от перегрева видимо треснула

https://bugs.python.org/issue27022

хренасе

@socketpair , ты?

да

Уважаемые, подскажите, у кого-нить работает OpenStack на AMD нодах?

123

Трансляцию или запись будет?

Кажется нет

судя по отсутствию аппаратуры для этого - нет.

Куда-то синтезоида дели

да вон сидит же

Теперь увидел )

Записи не будет чтоль? Плак, плак...

Симпа за браззерс лол

Про брфрс щас обидно было

А никто не сталкивался с тем что libvirt в segfault падает ? centos 7 libvirt 2 liberty virt_type=qemu

Хрыч, братишка

* падает при попытке запуска интсанса

Гопро появилась! Кажется будет запись

Уф

Я устал

Я устал

Где видос то?

Реквестирую презу интела

Хорошо если кинут ссылку

Я не знаю, есть ли тут докладчик. Миш попросишь его?

Да, спрошу

Грустно как-то...

Да не

Отлично вещает

Ну если дальше будет сводка, то норм. Пока четыре разбитых инфографики не очень удобно было слушать

http://www.slideshare.net/openstack_kr/openstack-days-korea-2016-track1-all-flash-ceph

в северной корее?

Это канал с упорантами, если что)

линк на запись скинуть не забудьте

https://plus.google.com/106346700132776512233

вот этого товарища кто-нибудь знает ?

https://plus.google.com/106346700132776512233

Ceph troubleshooting: "N pgs down" - OSD down - full 100%. ===================================== Коллеги, как запустить переполненный OSD (под счастливым номером 13)?

аааааааааааааааа

проорал

@alsvartr

проорал

а можно для тех кто в танке, что делать в этом случае ?

страдать и мучиться от собственного долбоебизма)

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

у тебя у цефа вылетает healt warn при 85% и health error при 95%, то есть он поправил себе лимиты, забил диск, а теперь страдает

нельзя взять сразу флоатинг сетку для старта инстанса

Можно

у тебя у цефа вылетает healt warn при 85% и health error при 95%, то есть он поправил себе лимиты, забил диск, а теперь страдает

эт я догадался. но всё же.

а что ты такого спросить у него хотел?