Вороне как-то бог послал кусочек сыру.
Ворона сыр схватила в носопыру,
И забралась ворона с дуру
На самую лесную верхотуру...

Ну а теперь серьезно.
Послал мне бог в лице непосредственного начальника второй идентичный уже имеющемуся у меня seagate barracuda 7200.7 40gb. Само собой дух исследователя и экспериментатора заставил меня снять с полки пылившийся там abit hotrod 100pro на hpt370, и соответственно взгромоздить на своем компьютере raid массив, причем тот, который stripe. Внимательно изучив, и тщательно законспектировав Библию, Коран и Руководство пользователя к контроллеру Abit HotRod 100pro, по найденным в последним источникам рекомендациям (на серверах предназначенных для обработки большого колличества файлов мелкого размера рекомендуется выставлять минимально-возможный размер блока), я выставил размер блока 16k. Рост производительности дисковой подсистемы действительно есть и он даже очень ощутимый. Но в душу мою закрались сомнения, вытянул-ли я все возможное???
Так вот, на просторах сети, советской и буржуйской я неоднократно находил информацию о зависимости производительности raid массива от типа применяемого контроллера. А меня интересует, измерял-ли кто-нибудь, где-нибудь, характеристику зависимости скорости случайного чтения/записи(как наиболее приближенного к реальности режима работы рабочей станции) от размера блока stripe массива.
Ведь хочется еще быстрее...

Все зависит от того, для чего используется комп и среднего размера файлов.... Чем больше размер блока, тем выше скорость (так как уменьшается время поиска), но тем больше места "теряется". Поэтому, если важна скорость, то выставляется 64k, если эффективное использование дискового пространства — то значение как можно меньшее. У меня например размер блока 64k. Разница весьма значительна. Однако же у меня мелких файлов совсем немного. Основная масса — графика (объемом в 200-500 мб), фильмы и пр... . Поэтому у меня такой размер блока оправдан Со всей "мелочью" я работаю на внешней магнитооптике.... потому как записывать ее на диск — это значит потерять уйму места

Sergey_nitol а размер блока stripe и размер кластера файловой системы — совершенно не связаны и ко времени поиска имеют опосредованное отношение. рекомендуют ставить 16к на сегодня, потому как он на сегодня соответсвует одному кластеру файловой системы, а уже размер кластера файловой системы имеет отношение к потере места.
и как бы совсем недопустимо, чтобы размер кластера (например 32к) ставился на размер блока stripe 16к — прямой путь к потере информации — хотя вроде как в этом случае производительность то и должна увеличиться.

AndreyPopov

Так я потому и говорю, что все определяется тем, для чего комп используется.... если у меня файлы по 500-1400 мегов, то никакой потери места практически нет.... а скорость увеличивается весьма существенно, особенно когда к компу одновременно обращаются 10-12 пользователей. Поэтому у меня размер блока (на трех системах) 64k (наиболее подходит для редактирования видео) и такой же размер кластера (хотя надо бы поставить 32k, так как винта 2 (чтобы работали параллельно). А со всей мелочью я работаю на магнитооптике.... В целом на серверах масштаба предприятия наибольшая производительность достигается при использовании 256k stripe (4 винта, размер кластера 64k)..... если хочешь более развернутых пояснений — пожалуйста. Возможно в прошлый раз я немного некорректно ответил по форме....

А в общем соотношение такое..... размер блока stripe 64k, размер кластера (64/кол-во винтов в массиве)................

Sergey_nitol а если винтов 3штуки? вопрос на засыпку хотя тут речь уже конечно о SCSI.

AndreyPopov

А у меня и есть SCSI.... на домашнем два Maxtor Atlas 15K (36.7GB, 15000 об./мин., Ultra320 Wide). Правда сейчас RAID-массив не работает, так как мощности блока питания не хватает... и так уж напруга проседает... скоро новый придется покупать... эдак на 460 Вт, чтобы на все хватило Вся система держится на одном винте (Жесткий диск IBM Ultrastar 146Z10 IC35L036UWDY10 36.7GB, 10000 об./мин., Ultra320 Wide) падение скорости по сравнению с RAID словами не описать

А на серваках и подавно SCSI.... 4 винта по 60 гигов каждый...

froGbI4

Глянь кось ссылку http://www.fcenter.ru/articles.shtml?hdd/1515#7 интересующий тебя тест.... по опыту (а он имеется )могу сказать, что для "среднего компа", используемого для монтажа звука/видео и игр наиболее оптимальным является размер блока stripe 64k (если два винта в массиве) и 128k (если 4 винта). Соответственно размер кластера файловой системы 32k

Господа, а вы тут не путаете размер блока, который обрабатывает контроллер массива и размер кластера файловой системы?

Это разные вещи и, строго говоря, обрабатываются они разными даже процессорами...
Размер блока на мой взгляд имеет резон определять из размера типичной дисковой операции записи — таким образом, чтобы при записи писать блоки целиком и минимально по количеству. Так, например, при типичной записи 10 кб и блоке 128кб придется считать 128кб, внести изменения в блок и затем записать на место, понятно, что для ускорения работы в такой ситуевине надо брать возможно меньший размер блока — 16кб (или даже 8). Так вот, определив типичный размер дисковой операции записи и нужно выбирать размер блока.

Соотношение (размер самой важной с т.з. быстродействия операции)/(размер блока) должно стремиться к единице, это позволит уменьшить накладные расходы при работе контроллера и, естественно, повысит быстродействие системы.

Для типичного десктопа по моей оценке размер блока где-то 32-64к (для двух дисков). Для сервера — надо мерять в каждом конкретном случае, но обычно получается побольше, 64-128. Для потоковых серверов — имеет резон ставить максимально возможное значение.

РОВНО ТЕ ЖЕ РАССУЖДЕНИЯ проделываются и в отношение кластеров файловой системы, но тут уже начинает "играть" размер потерь на "хвостах" кластеров.

Stranger_NN

Господа, а вы тут не путаете размер блока, который обрабатывает контроллер массива и размер кластера файловой системы?

А где это я написал, что это одно и тоже? Я же вроде и поянил, что конкретный размер зависит от того, для чего используется компьютер, размера файлов, количества дисков в массиве....

"для "среднего компа", используемого для монтажа звука/видео и игр наиболее оптимальным является размер блока stripe 64k (если два винта в массиве) и 128k (если 4 винта)."

Stranger_NN

Относительно твоего замечания Так, например, при типичной записи 10 кб и блоке 128кб придется считать 128кб, внести изменения в блок и затем записать на место, понятно, что для ускорения работы в такой ситуевине надо брать возможно меньший размер блока — 16кб (или даже 8). Так вот, определив типичный размер дисковой операции записи и нужно выбирать размер блока.

Предполагая использование файловой системы ext2fs, и текущих правил ядра для упреждающего чтения, большие размеры stripe почти всегда лучше, чем маленькие размеры, и размеры stripe от почти четырех до полного цилиндра диска наилучшие. Чтобы понять это требование, рассмотрим эффективность больших stripe на маленьких файлах, и маленьких stripe на больших файлах. Размер stripe не влияет на производительность чтения на маленьких файлах: для массива из N дисков, файл имеет 1/N вероятность попасть целиком в один stripe на любой диск. Таким образом, и задержка и производительность чтения сравнима с чтением одного диска. Предположим, что маленькие файлы статистически хорошо распределяются по файловой системе, (и, на файловой системе ext2fs, они должны), грубо в N раз более упорядочены, конкурентные чтения должны быть возможны без значительных коллизий между ними. Наоборот, если используются очень маленького размера stripe-ы, и последовательно читается большой файл, то чтение будет выдаваться всем дискам массива. Для чтения одного большого файла, задержка будет почти двойная, так как увеличивается вероятность нахождения блока в трех четвертях оборота диска или далее. Однако заметьте аргумент: пропускная способность может увеличиться почти в N раз для чтения одного большого файла, так как N дисков могут читать одновременно (то есть, если используется упреждающее чтение, то все диски остаются активными). Но есть другй контр-аргумент: если все диски уже заняты чтением файла, то попытки одновременного чтения второго или третьего файла приведут к значительной борьбе, разрушив производительность, так как алгоритмы управления диском будут двигать головками вдоль пластины. Таким образом, большие stripe-ы будут почти всегда приводить к большей производительности. Единственное исключение — случай, при использовании хорошего алгоритма упреждающего чтения, где один поток в одно время читает один большой файл, и он требует наивысшей возможной производительности. В этом случае желательны небольшие stripe-ы.

Хотя это и касается Linux.... неоднократно проверял... и практически полностью согласен

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

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

Stranger_NN

похоже

Безусловно.... теоретические выводы не безосновательны...
использование компьютера — обычный (домашний) multimedia комбайн, в сочетании с печатной мошинкой.
временами баловство в adobe premiere...
Таким образом не зря при построении массива, по умолчанию, предлагается использовать stripe-блок размером 64k.

Но сразу возникает другой вопрос. ведь установка блока скажем 2 мегабайта приведет к перекрыванию размера кеша отдельного жесткого диска (1mb для barracuda 7200.7) и как результат должно привести к простою, после передачи первого мегабайта на время освобождения кеша (убить этот простой и есть цель stripe массива)... т.е. разумно предположить, что график производительности должен иметь скорее один максимум, нежели быть линейным.

froGbI4

Практика (моя... на 4 серверах и 7 рабочих станциях) показала, что использование размера stripe-блока более 256k в принципе прироста не дает. Куда больший прирост дает увеличение количества дисков в массиве.

Sergey_nitol
Куда больший прирост дает увеличение количества дисков в массиве.
ну так.

но это относится к SCSI.

у IDE RAID контроллеров структура другая и протоколы.

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

для двух винтов самым быстродействующим должен быть вариант, когда размер блока stripe'а в два раза меньше кластера файловой системы.
хотя тут бабка на двое сказала, потому как реально в дешевых картах реализован BIOS и как написан драйвер, много разных НО.

AndreyPopov

А у меня и есть SCSI (см выше).... а то, что в глубины копнули... так только началали а человеку я рекомендацию дал.... IDE RAID я куда меньше юзал (я к нему отношусь прохладно... у меня вот мамка ASUS P4C800 c RAID так я все равно пользуюсь SCSI... намногг быстрее получается.... а человеку я рекомендацию дал.. и ссылку на тесты... его интересующие, потому как результаты своих я давно "убил" за ненадобностью, а тестить заново нет возможности

но насчет

Цитата:

---

>для двух винтов самым быстродействующим должен быть вариант, когда размер блока stripe'а в два раза меньше кластера файловой системы\

---

могу с тоюой поспорить

Sergey_nitol — могу с тоюой поспорить — а сам что писал?

Цитата:

---

>А в общем соотношение такое..... размер блока stripe 64k, размер кластера (64/кол-во винтов в массиве)................\

---

AndreyPopov

Так ты ж написал, что размер блока stripe должен быть в два раза МЕНЬШЕ КЛАСТЕРА файловой системы, а я считаю (на основании многочисленных тестов как серверов, используемых для бизнес-приложений, так и для поддержания сайтов), что .... ты привел мою цитату то есть когда размер КЛАСТЕРА меньше размера блока stripe пропорционально кол-ву дисков.... ты ж привел мою цитату....

Sergey_nitol да уж запутался в переверт туда сюда.

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

AndreyPopov

Цитата:

---

>все завист от алгоритма реализованного производителем и соответсвенно драйвера.</SPAN><HR size=22></SPAN></BLOCKQUOTE> Согласен на все 100% Особенно большую (можно сказать главную роль) играет алгоритм упреждающего чтения А вот относительно <BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>по идее для двух IDE винтов на двухканальном IDE RAID, когда пол-кластера пишется на один, а вторая половина на другой — должен быть наиболее быстродействующим вариантом\

---

в принципе часто максимальную производительность дает установка stripe равным кэшу диска.... хотя... у меня на винтах SCSI по 8 мб кэш... такой размер stripe не выставить. А в принципе, если не заморачиваться с "выдавливанием" 1-2% производительности, то ты прав. Это наиболее оптимально для большинства систем.