цеф таки умеет в параллельные запросы при писании на один диск

Ээ

всмысле один осд может нахерачить много параллельных запросов на один диск

может это и капитанство, но напрямую это нигде не сказано

А

поэтому, сцуко, NCQ пиздец как важно. и мои эксперименты показывают, что на само мделе нихера оно не работает

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

что на дешмани, что на velociraptor с наклейкой "Enterprise Storage"

Я надеюсь ты как хороший мальчик потом напишешь пост хотя бы сюда о своих изысканиях

ниасилю. да и не уверен пока насчёт правильности моих измерений

пока мне кажется, что руки у меня из жопы, но как это проверить?

вот например недавно зависал fio - я думаю что за дерьмо

а оказалось я забыл приписать direct=1

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

поэтому, сцуко, NCQ пиздец как важно. и мои эксперименты показывают, что на само мделе нихера оно не работает

sas надо, там работает, у sata оно сильно кастрировано

sas надо, там работает, у sata оно сильно кастрировано

эумперимент показывает. что даже пару-тройку секоторов за раз не прописывает, какой смысл?

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

LSI в доках к контроллерам подробно расписывало где и насколько, но сейчас под рукой нет

но блять, даже 2-3 это предел

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

или контроллер

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

Шо? Разьве там есть поддержка нескольких очередей?

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

он очень много чего позволяет сверх возможностей sata

или фаза луны

он очень много чего позволяет сверх возможностей sata

например, из того что пригодится именно в цефе

Шо? Разьве там есть поддержка нескольких очередей?

ну NCQ же

он очень много чего позволяет сверх возможностей sata

scsi много чего позволяет

scsi много чего позволяет

а из того что пригодится в цефе ?

ну NCQ же

ncq - это одна очередь

В scsi тоже одна очередь

Несколько очередей есть только в nvme

ладно, окей, очередь одна

но линукс зная это — в неё вталкивает по 32 сектора по одному из каждой линуксной очереди

sas как железо реализующее возможности протокола SCSI

(условно)

но линукс зная это — в неё вталкивает по 32 сектора по одному из каждой линуксной очереди

Нет

Нет

а как тогда?

Что как?

БЛДЖАД

в чём смысл NCQ тогда ?

но линукс зная это — в неё вталкивает по 32 сектора по одному из каждой линуксной очереди

вот откуда у тебя такое предположение?

Это очередь. Одна очередь. Но контроллер диска с ncq может задания из этой очереди перемешать так, чтобы они выпонились эффективнее

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

Это очередь. Одна очередь. Но контроллер диска с ncq может задания из этой очереди перемешать так, чтобы они выпонились эффективнее

верно

у нас есть как минимум 2 очереди: 1) это та самая nr_requests 2) очередь в самом блочном устройстве (ncq/tcq)

у нас есть как минимум 2 очереди: 1) это та самая nr_requests 2) очередь в самом блочном устройстве (ncq/tcq)

окей

(nr_requests кстати только в noop)

более того, запросы из очереди 1 не всегда попадают в 1 в 1 в очередь 2

более того, запросы из очереди 1 не всегда попадают в 1 в 1 в очередь 2

понятное дело

(nr_requests кстати только в noop)

везде.

везде.

а редхат в пдф говорит что нет

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

а редхат в пдф говорит что нет

что именно оно говорит? линк? вот у меня deadline и тоже есть nr_requests

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/ch06s04s03.html

в cfq тоже оно есть, как и bfq

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/ch06s04s02.html

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/ch06s04s03.html

это на block level, а не на уровне элеватора

мож оно есть, но не влияет при деадлайне ?

мож оно есть, но не влияет при деадлайне ?

влияент везде.

>Following are the tunables available for the block layer.

это на block level, а не на уровне элеватора

вот тут поподробнее, пожалуйста, потому что я не понял

ну йопт

щас понял.

tunables для элеватора живут в /sys/block/sda/queue/iosched/

пдф оформляли пидоры

для noop ясен хер что никаких tunables нет потому что и элеватора нет

так. окей. продолжаем

но block level никуда не делся

ок. жутко интересно про NCQ

жги.

так вот, если у тебя i/o будет больше чем max_sectors_kb, то запрос побьётся и попадёт в очередь устройства уже в виде нескольких

(не всмысле, мол, ну давай, давай, спори хуйню, а реально интересно)

ок. жутко интересно про NCQ

а что про неё говорить? ncq - это просто очередь и возможность для контроллера диска иметь пространство для оптимизации.

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

так вот, если у тебя i/o будет больше чем max_sectors_kb, то запрос побьётся и попадёт в очередь устройства уже в виде нескольких

ну. тоесть линукс потенциально копит запросы чтобы потом протолкнуть их в диск всеё пачкой. верно ?

и копилки эти по-процессно. верно ?

а из того что пригодится в цефе ?

От нагрузки зависит, к примеру sas передаёт в дуплексе данные, в случае больших массивов может быть полезно, не блокирует порт 1 устройством в случае использования експандеров

ну. тоесть линукс потенциально копит запросы чтобы потом протолкнуть их в диск всеё пачкой. верно ?

он копит в своей очереди

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

От нагрузки зависит, к примеру sas передаёт в дуплексе данные, в случае больших массивов может быть полезно, не блокирует порт 1 устройством в случае использования експандеров

экспандеров нет (у меня) нагрузка в основном на запись.

и копилки эти по-процессно. верно ?

не уверен, что per process. скорее, per device.

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

какого именно wiki?

экспандеров нет (у меня) нагрузка в основном на запись.

я предлагаю подумать над относительно простым сценарием: у тебя аппаратный рейд и пачка дисков с ncq. у рейда будет tcq с глубиной очерди в 255 команд + очереди ncq в дисках. + очередь в linux к блочному устройству рейда.

я предлагаю подумать над относительно простым сценарием: у тебя аппаратный рейд и пачка дисков с ncq. у рейда будет tcq с глубиной очерди в 255 команд + очереди ncq в дисках. + очередь в linux к блочному устройству рейда.

чота сложна пока.

у меня рэйдов нет и не планируется

будут по 4 диска в ноде

какого именно wiki?

https://en.wikipedia.org/wiki/Serial_Attached_SCSI#Comparison_with_SATA

под цеф

будут по 4 диска в ноде

тогда забей на sas

а я и забил. вопрос был про NCQ и полезен ли он в цефе.

пока не станет много или/и диски не станут БЫСТРЫМИ тебе sas не нужен

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

пока не станет много или/и диски не станут БЫСТРЫМИ тебе sas не нужен

мне нужно собрать из говна и палок. но всё же, в говне поискать орешки

кароче.

как проверить NCQ в деле ? (измерить тоесть)

а стоп.

как проверить NCQ в деле ? (измерить тоесть)

тупо queue depth менять

погодите.

тупо queue depth менять

так и делаю . в фио

погодите.