На этот раз - о быстродействии UFS2 на программном RAID (ccd). Измерения проводились для UFS2 и EXT2 на обычных разделах и UFS2 на программном RAID0. Результат - производительность раздела на RAID0 (логическое объединение IDE дисков) значительно выше, но это не заслуга UFS.URL: http://unix.ginras.ru/freenotes/test/ufs-and-ccd.html
Новость: http://www.opennet.ru/opennews/art.shtml?num=3981
пробовали тестировать UFS2 + async - softupdates ?
шустрая как электровеник
Чего нет - того нет. Спасибо, попробую. А не страшно?
Не шустрее. В обсуждении прошлой истории уже протестили.
в обсуждении прошлой истории тестили async + softupdates
а я предлагаю async - softupdatesна операциях с самбой быстрее в три раза (на тех операциях, которые требуют большого количества маленьких файлов)
При работе с диском обычно время задержки (позиционирование головки плюс время ожидания прихода нужного сектора под головку) важнее, чем скорость трансфера (чтения или записи).Время ожидания прихода нужного сектора под головку составляет в среднем:
- половину оборота диска при одном диске;
- две трети оборота диска при RAID-0 на двух дисках (нужно ждать того, кто откликнется позже).
Позиционированием головки в этом слцчае мы можем пренебречь. Получается, что время ожидания играет решающую роль при работе блоками менее примерно двухсот килобайт (и по мере роста ёмкости дисков эта величина тоже растёт, хотя и медленнее). А обращения в системные области диска (в директории, в таблицы размещения файлов, в таблицы свободного места) не м.б. большими (правда, они кэшируются, но записвать их всё равно надо).Так что ускорения от RAID-0 массива ждать не приходится, не говоря уж о др.схемах.
А можно поподробнее про "две трети оборота в случае RAID-0"? Что-то мои доморощенные знания теории вероятности такого вывода не позволяют сделать.
И уж тем более здравый рассудок не позволяет принять того, что "ускорения ждать не приходится". Зависит исключительно от размера и типа кэша. RAID-5 например при чтении работает как RAID-0 на N-1 дисках.
И откуда цифра в 200Кб? Размер блоков разный бывает.
Что-то где-то кто-то там, одним словом.
> А можно поподробнее про "две трети оборота в случае RAID-0"?
> Что-то мои доморощенные знания теории вероятности такого вывода не позволяют сделать.Запрос прихожит в случайное время. Оба диска находятся в случайном положении. Оба времени ожидания прихода сектора под головку (обозначим их X и Y) независимы и равномерно распределены в интервале {от 0 до 1}. Нам нужно максимальное. Берём двойной интергал:
{интеграл от 0 до 1} ( {интеграл от 0 до 1} ( max(X,Y) dX dY ) )
Дальше брать или не надо?> И уж тем более здравый рассудок не позволяет принять того, что "ускорения ждать не приходится".
Реально бывает как ускорение, так и замедление. Это - тема двухчасовой лекции. Хочешь - организуй мне аудиторию и оплату, у меня есть что рассказать "городу и миру" (я уже преподаю в МФТИ, но хочу расширить свою преподапвательскую деятельность).
> Зависит исключительно от размера и типа кэша.
Какого кэша? Я в твоей машине с ходу назову тебе четыре кэша и штук пять процессоров.
> RAID-5 например при чтении работает как RAID-0 на N-1 дисках.
И чем больше дисков, тем больше начальная задержка.
> И откуда цифра в 200Кб? Размер блоков разный бывает.
Ну хорошо - 200 KB. Скорость IDE-диска при работе с перефирийными треками примерно в два раза меньше скорости интерфейса; умножаем это на время полуоборота...
>> А можно поподробнее про "две трети оборота в случае RAID-0"?
>> Что-то мои доморощенные знания теории вероятности такого вывода не позволяют сделать.
>
>Запрос прихожит в случайное время. Оба диска находятся в случайном положении. Оба
>времени ожидания прихода сектора под головку (обозначим их X и Y)
>независимы и равномерно распределены в интервале {от 0 до 1}. Нам
>нужно максимальное. Берём двойной интергал:
>{интеграл от 0 до 1} ( {интеграл от 0 до 1} ( max(X,Y) dX dY ) )
>Дальше брать или не надо?1. запрос может уложиться в один блок (то есть чтение производится только с одного диска)
1a. куча мелких запросов достаточно равномерно распредляется между дисками и мы видим фактически уменьшение времени доступа по сравнению с однодисковой системой
2. блок может быть достаточно большим (то есть за время, пока с первого диска читается блок второй диск ищет следущий - начальное состояние второго диска уже не имеет значения)
3. есть raid1. при правильной организации надо брать
{интеграл от 0 до 1} ( {интеграл от 0 до 1} ( min(X,Y) dX dY ) )в частности raid10 показывает обычно очень хорошие результаты на чтение (и на запись), но к сожалению слишком зависит от реализации
edo:
> 1. запрос может уложиться в один блок (т.е. чтение производится только с одного диска)Правильно. Я же говорил, что это - тема часа на два, а то и более. Тут мы сталкиваемся с вопросом о быьоре "блока черелования": если чётные секторы логического диска находятся на одном физическом, а чётные на другом (RAID-0 из двух дисков), то при запросе более одного сектора задержка сразу вырастает с полуоборота до двух/третей.
Предлагаю специалистам (тем, кто считает себя таковыми) решить задачу о выборе оптимального размера "блока черелования".
Иными словами, на маленьком запросе особой выгоды мы не получим - выгода возможна только на больших запросах - больше, чем оптимальный размер "блока черелования". Для того, чтобы оперировать такими запросами, надо иметь нехилый объём оперативной памяти на борту.
> 1a. куча мелких запросов достаточно равномерно распредляется между дисками и мы видим фактически уменьшение времени доступа по сравнению с однодисковой системой
Да - для этого RAID-контроллер должен работать в SCSI-стиле: принимать пачку запросов и распределять их самомтоятельно. И иметь на себе нехилый объём собственной памяти (десятки мегабайт).
Плюс к тому, следует различать операции чтения (которые в принципе можно полностью буферизовать при большом объёме RAM) и операции записи (которые придётся делать на случая сбоя питания).
Те, кто знакомы с понятием "транзакция", знают, что диск (дисковая система) не имеет права менять очер`дность выполнения операций записи, выполняющихся в ходе одной транзакции; так что свобода маневра у RAID-контроллера сильно ограничена.> 2. блок может быть достаточно большим (то есть за время, пока с первого диска читается блок второй диск ищет следущий - начальное состояние второго диска уже не имеет значения)
Это я рассмотрел выше.
> 3. есть raid1. при правильной организации надо брать
{интеграл от 0 до 1} ( {интеграл от 0 до 1} ( min(X,Y) dX dY ) )Это если контроллер умеет посылать запрос сразу к двум дискам и выбирать отает от того, кто ответил первым. Такое умение отражено в документации?
Дмитрий:
> Ну и у задержки есть предел ;-) !Да - при увеличении количества дисков задержка стремится к полному обороту диска.
> И на сколько нам интересна первоначальная задержка?
Обрати внимание, что продавцы указывают именно скрорость вращения (главный параметр, определяющий задержку), а не скорость чтения/записи! Да ради снижения задержки производители перешли от пятидюймовых дисков к трёхдюймовым, потеряв в два с лишним раза площадь поверхности (и, соответвтсенно, ёмкости)!!! Ну так что же важнее, а?
> Если только нам делать больще нечего, то пожалуй. Если ввести асинхронность в процесс обмена с дисками, и считаем задачу выполненной после значительного количества найденных и прочитанных блоков самым невезучим диском, то некоторое увеличение начальной задержки не имеет значения.
Есть вещи, которые нельзя выполнять асинхронно - см.выше про "транзакции".
> RAID лишь немногим хуже одинночного диска по затратам времени на каждое позиционнирование.
При двух дисках - в 1.33 раза. Это немного?
toor99:
> У теоретиков все так: если практика не сходитсч с теорией, то тем хуже для практики. Забей.Не далее как вчера я спорил со студентом МФТИ. Я говорил, как OS (любая) должна работать с виртуальной памятью по моемУ мнению; а он говорил, что программирует под Linux, и там всё не так. Он позвонил другому преподу, потом полез в листинги компиляции - и выяснилось, что я такИ прав. И действительно - не могли же авторы Linux не додуматься до тех вещей, которые мне очевидны!
>
>> И на сколько нам интересна первоначальная задержка?
>
>Обрати внимание, что продавцы указывают именно скрорость вращения (главный параметр, определяющий задержку),
>а не скорость чтения/записи! Да ради снижения задержки производители перешли от
>пятидюймовых дисков к трёхдюймовым, потеряв в два с лишним раза площадь
>поверхности (и, соответвтсенно, ёмкости)!!! Ну так что же важнее, а?
>
Это не то, разговор шел именно о важности начала чтения, и если бы это только одно разовое чтение, я бы согласился.
>
>Есть вещи, которые нельзя выполнять асинхронно - см.выше про "транзакции".
>Транзакция или важность сохранения порядка записи на диск IMHO не причем.
RAID не должен переписывать очереди, он должен баланисровать нагрузку и не давать запрос чтения на диск с самой длинной очередью заданий. Всего лишь - грубо так.Что касается параллельной отработки заданий дисками, делящих шину на контроллер (клинический случай), то это уже сделано. Для передачи данных им конечно придеться разобраться друг с другом, но готовить данные они смогут одновременно, веротяно что и между командой на запись и подтверждением выполнения записи шина остаеться свободной ( не уверен ).
Поддерживает ли возможность параллельного работы конкретный контроллер и диски - придеться разбираться. Но скорее всего ДА !
>> RAID-5 например при чтении работает как RAID-0 на N-1 дисках.
>
>И чем больше дисков, тем больше начальная задержка.
>
Ну и у задержки есть предел ;-) !
И на сколько нам интересна первоначальная задержка? Если только нам делать больще нечего, то пожалуй. Если ввести асинхронность в процесс обмена с дисками, и считаем задачу выполненной после значительного количества найденных и прочитанных блоков самым невезучим диском, то некоторое увеличение начальной задержки не имеет значения. RAID лишь немногим хуже одинночного диска по затратам времени на каждое позиционнирование.Raid5 явно увеличит отношение кол-во_позиционирований/кол-во_данных для каждого диска. Если бы удалось ровномерно распределить файловые операции по дискам без RAID, то это было бы эффективней, чем теже дисковые операции с единым блочным устройством на основе обьеденных в RAID дисков. Осталось только найти некий новый способ балансировки нагрузки.
А для RAID-а неплохо использовать предварительное чтение, не скупиться на буфера, вдруг все получиться не так печально..
>А можно поподробнее про "две трети оборота в случае RAID-0"? Что-то мои
>доморощенные знания теории вероятности такого вывода не позволяют сделать.
>И уж тем более здравый рассудок не позволяет принять того, что "ускорения
>ждать не приходится". Зависит исключительно от размера и типа кэша. RAID-5
>например при чтении работает как RAID-0 на N-1 дисках.
>И откуда цифра в 200Кб? Размер блоков разный бывает.
>Что-то где-то кто-то там, одним словом.У теоретиков все так: если практика не сходитсч с теорией, то тем хуже для практики. Забей.
Если этот тот же Федорчук, что и авторhttp://cs.mipt.ru/docs/comp/rus/os/unix/user_guide/fedorchuk...
(http://www.yandex.ru/, искать Федорчук xedit)
то увы, без скепсиса, к его творениям, мне относиться уже не удается:
"...
Этот редактор - прост, как грабли (или реклама в бозе почившей фирмы Сэлдом). Белый экран с тремя пунктами меню в верхней части (Quit, Save, Load). Ниже - рабочее поле с миниатюрными, совершенно непосильными для моего зрения буквами (рис. 3). Полная невозможность настроить чего бы то ни было - размер и гарнитуру шрифта, не говоря уже о шрифтоначертании или цвете фона....
Открытие файла сделано далеко не блестяще - нужно набрать путь либо в командной строке, либо после еле заметной галочки вслед за пунктом меню Load...."
Это про xedit. :-) Который умеет C-код "раскрашивать", и вообще,
почти что маленький брат emacs'а.В общем, вот так вот. :-/
/poige
--
http://www.i.morning.ru/~poige/
Так выходит дело не в USF, а в работе FreeBSD с дисками?
Моё чисто субъективное мнение: 5 CURRENT работает заметно медленнее, чем 4.10.
>Так выходит дело не в USF, а в работе FreeBSD с дисками?
>
>Моё чисто субъективное мнение: 5 CURRENT работает заметно медленнее, чем 4.10.Почитайте /usr/src/UPDATING