Сравнительная таблица пенальти IO для hdd.

есть куча разных затыков на размерах секторов

если только в программе рандомный (или последовательный, но директный) доступ организован по 512 байт, а размер сектора на новом диске 4096, то еще можно такое представить

выравнивании партиций, RAID и т.п.

это вообще бред

Не попадались ли кому сводная табличка

гы-гы

это вообще бред

во-во ..
вот смотри : производительность теряется, если партиция не выровнена - это факт
есть разные пенальти на типы рейдов - это факт
эмуляция 512 секторов тоже накладывает пенальти - это факт
эти все траблы могут комбинировться - это факт.

gparted выравнивает по мегабайту и норм.

https://access.redhat.com/labs/lvmraidcalculator/

вход для подписчиков

выглядит так http://imgur.com/Q04k4Xk

это то причем ?
я про такое http://theithollow.com/2012/03/21/understanding-raid-penalty/
только покрывающее все слои работы с hdd

калькулятор для разных типов raid, lvm и всего такого ?

Дал тебе «raid, lvm и всего такого»

Скажите, а Вам не знакомо такое понятие, как контекст ?

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

я про такое http://theithollow.com/2012/03/21/understanding-raid-penalty/

It is fairly simple to calculate the penalty for RAID 1 since it is a mirror. The write penalty is 2 because there will be 2 writes to take place, one write to each of the disks.

дальше можно не читать

и что не так?

тебе чтобы сварить вкрутую 6 яиц нужно потратить целый час?

тебе чтобы сварить вкрутую 6 яиц нужно потратить целый час?

так вот я и не знаю как это всё суммируется.
допустим у меня диски с секторами 512е на mdadm raid 10 в кол-ве 8 штук, внутрях lvm с ext4 поверх.
Как посчитать пенальти для такого случая ?
Что лучше, lvm держать на выровненной партиции или целиком диск отдать ?

то, что они запишутся почти одновременно, не отменяет того, что io будет два вместо одного.

если не делать глупостей, например, RAID1 на разделах одного диска, то просадка в скорости будет ~0.01%

заметный эффект может быть только из-за размеров секторов, о чем я уже писал выше: 4KB/512B=8, но это касается только чистой скорости чтения/записи с поверхности, а еще нужно учесть, что на таких малых блоках бо́льшую часть времени операции будет занимать позиционирование головок в нужное место диска: например, при размере сектора 512 операция его чтения занимала 10us (9us позиционирование и 1us собственно чтение 512 байт); теперь при размере сектора 4K на получение блока в 512 байт нужно будет затратить те же 9us на позиционирование и 1*8=8us на чтение 4K сектора — итого 9+8=17us; т.е. это уже не в 8 раз медленнее, а всего лишь в 1.7

io будет два вместо одного

да, но и скорость железки у тебя изменилась, ведь у тебя теперь два hdd, и она обеспечивает двойной iops
мы же за скорость здесь переживаем, а не за количество

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

и 1*8=8us на чтение 4K сектора — итого 9+8=17us

а теперь добавь туда ещё считывание второго сектора, если разделы не выровнены. с записью всё ещё веселее.

да, еще одну лишнюю, но теперь два io будет выполнено параллельно за то же время, что и одно io в конфигурации без рейда — ходишь по кругу, про яйца я уже говорил

что за бред? какие разделы? причем здесь разделы?
если у него приложение читало кусками, которые не выровнены по 512 байтовым секторам, то значит и раньше это приводило к подъему с диска двух секторов, так что при переходе на 4K-сектор уже не всегда нужно будет читать два сектора, а только в одном случае из восьми, так что расчет будет еще оптимистичнее

что за бред? какие разделы? причем здесь разделы?

Вот и я читаю все это, и ощущение, толи я незаметно сам для себя накурился, то ли участники топика курили вместе, то ли я что-то в этой жизни пропустил.

Табличек и калькуляторов нет, но есть https://wiki.kernel.org/

Выравниваешь таблицу разделов по границам, кратным числу из /sys/class/block/sdc/queue/physical_block_size.

Если создаешь mdraid, имей ввиду, что метаданные версий 1.1 и 1.2 занимают 1 килобайт в начале раздела (если в массиве не больше 384 дисков), это два сектора.

Создавая lvm, нужно жестко иметь это ввиду и делать что-то вроде pvcreate --dataalignmentoffset 1022s --dataalignment 512k /dev/md1, чтобы отодвинуть pv до начала границы нового страйпа. --dataalignment должен быть равен «Chunk Size» твоего raid. --dataalignmentoffset рассчитывается по-разному в зависимости от типа массива.

При создании ФС делаешь mkfs.ext4 -v -b 4096 -E stride=32,stripe-width=64 /dev/md0, где
chunk size = 128kB — Размер чанка твоего raid
-b 4096 — размер блока (не сектора) жесткого диска
stride = chunk / block
stripe-width = stride * N, где N — количество дисков с данными в массиве, например для raid6 из 5 дисков, один из которых spare, N=5-1-2=2.

Я пользовался bc, если встроенного не хватало.

вот это годный ответ !

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

С тобой ещё в треде про ленты всё ясно было.

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

это тебе рабинович напел?

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

ессно не читатель, когда

Log in to your Red Hat account

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

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

это то причем ?
bdfy (19.05.2016 17:55:23)

при том, что там как раз про то что

вот это годный ответ !