|
| |
| 2.14, Илья Шипицин (?), 14:18, 15/06/2004 [^] [^^] [^^^] [ответить]
| +/– |
 в обсуждении прошлой истории тестили async + softupdates
а я предлагаю async - softupdates
на операциях с самбой быстрее в три раза (на тех операциях, которые требуют большого количества маленьких файлов) | | |
|
| 1.4, Дмитрий Ю. Карпов (?), 21:24, 13/06/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 При работе с диском обычно время задержки (позиционирование головки плюс время ожидания прихода нужного сектора под головку) важнее, чем скорость трансфера (чтения или записи).
Время ожидания прихода нужного сектора под головку составляет в среднем:
- половину оборота диска при одном диске;
- две трети оборота диска при RAID-0 на двух дисках (нужно ждать того, кто откликнется позже).
Позиционированием головки в этом слцчае мы можем пренебречь. Получается, что время ожидания играет решающую роль при работе блоками менее примерно двухсот килобайт (и по мере роста ёмкости дисков эта величина тоже растёт, хотя и медленнее). А обращения в системные области диска (в директории, в таблицы размещения файлов, в таблицы свободного места) не м.б. большими (правда, они кэшируются, но записвать их всё равно надо).
Так что ускорения от RAID-0 массива ждать не приходится, не говоря уж о др.схемах. | | |
| |
| 2.5, Ivan Voytas (?), 11:37, 14/06/2004 [^] [^^] [^^^] [ответить]
| +/– |
 А можно поподробнее про "две трети оборота в случае RAID-0"? Что-то мои доморощенные знания теории вероятности такого вывода не позволяют сделать.
И уж тем более здравый рассудок не позволяет принять того, что "ускорения ждать не приходится". Зависит исключительно от размера и типа кэша. RAID-5 например при чтении работает как RAID-0 на N-1 дисках.
И откуда цифра в 200Кб? Размер блоков разный бывает.
Что-то где-то кто-то там, одним словом. | | |
| |
| 3.6, Дмитрий Ю. Карпов www.prof.pi2.ru (?), 12:05, 14/06/2004 [^] [^^] [^^^] [ответить]
| +/– |
> А можно поподробнее про "две трети оборота в случае 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-диска при работе с перефирийными треками примерно в два раза меньше скорости интерфейса; умножаем это на время полуоборота... | | |
| |
| 4.7, edo (?), 12:27, 14/06/2004 [^] [^^] [^^^] [ответить]
| +/– |
>> А можно поподробнее про "две трети оборота в случае 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 показывает обычно очень хорошие результаты на чтение (и на запись), но к сожалению слишком зависит от реализации | | |
| |
| |
| 6.15, Dmitry (??), 15:07, 15/06/2004 [^] [^^] [^^^] [ответить]
| +/– |
 >
>> И на сколько нам интересна первоначальная задержка?
>
>Обрати внимание, что продавцы указывают именно скрорость вращения (главный параметр, определяющий задержку),
>а не скорость чтения/записи! Да ради снижения задержки производители перешли от
>пятидюймовых дисков к трёхдюймовым, потеряв в два с лишним раза площадь
>поверхности (и, соответвтсенно, ёмкости)!!! Ну так что же важнее, а?
>
Это не то, разговор шел именно о важности начала чтения, и если бы это только одно разовое чтение, я бы согласился.
>
>Есть вещи, которые нельзя выполнять асинхронно - см.выше про "транзакции".
>
Транзакция или важность сохранения порядка записи на диск IMHO не причем.
RAID не должен переписывать очереди, он должен баланисровать нагрузку и не давать запрос чтения на диск с самой длинной очередью заданий. Всего лишь - грубо так.
Что касается параллельной отработки заданий дисками, делящих шину на контроллер (клинический случай), то это уже сделано. Для передачи данных им конечно придеться разобраться друг с другом, но готовить данные они смогут одновременно, веротяно что и между командой на запись и подтверждением выполнения записи шина остаеться свободной ( не уверен ).
Поддерживает ли возможность параллельного работы конкретный контроллер и диски - придеться разбираться. Но скорее всего ДА !
| | |
|
|
| 4.9, Дмитрий (??), 00:53, 15/06/2004 [^] [^^] [^^^] [ответить]
| +/– |
>> RAID-5 например при чтении работает как RAID-0 на N-1 дисках.
>
>И чем больше дисков, тем больше начальная задержка.
>
Ну и у задержки есть предел ;-) !
И на сколько нам интересна первоначальная задержка? Если только нам делать больще нечего, то пожалуй. Если ввести асинхронность в процесс обмена с дисками, и считаем задачу выполненной после значительного количества найденных и прочитанных блоков самым невезучим диском, то некоторое увеличение начальной задержки не имеет значения. RAID лишь немногим хуже одинночного диска по затратам времени на каждое позиционнирование.
Raid5 явно увеличит отношение кол-во_позиционирований/кол-во_данных для каждого диска. Если бы удалось ровномерно распределить файловые операции по дискам без RAID, то это было бы эффективней, чем теже дисковые операции с единым блочным устройством на основе обьеденных в RAID дисков. Осталось только найти некий новый способ балансировки нагрузки.
А для RAID-а неплохо использовать предварительное чтение, не скупиться на буфера, вдруг все получиться не так печально..
| | |
|
| 3.10, toor99 (ok), 01:52, 15/06/2004 [^] [^^] [^^^] [ответить]
| +/– |
 >А можно поподробнее про "две трети оборота в случае RAID-0"? Что-то мои
>доморощенные знания теории вероятности такого вывода не позволяют сделать.
>И уж тем более здравый рассудок не позволяет принять того, что "ускорения
>ждать не приходится". Зависит исключительно от размера и типа кэша. RAID-5
>например при чтении работает как RAID-0 на N-1 дисках.
>И откуда цифра в 200Кб? Размер блоков разный бывает.
>Что-то где-то кто-то там, одним словом.
У теоретиков все так: если практика не сходитсч с теорией, то тем хуже для практики. Забей.
| | |
|
|
| 1.8, poige (??), 13:17, 14/06/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Если этот тот же Федорчук, что и автор
http://cs.mipt.ru/docs/comp/rus/os/unix/user_guide/fedorchuk/office/2/002xedi
(http://www.yandex.ru/, искать Федорчук xedit)
то увы, без скепсиса, к его творениям, мне относиться уже не удается:
"...
Этот редактор - прост, как грабли (или реклама в бозе почившей фирмы Сэлдом). Белый экран с тремя пунктами меню в верхней части (Quit, Save, Load). Ниже - рабочее поле с миниатюрными, совершенно непосильными для моего зрения буквами (рис. 3). Полная невозможность настроить чего бы то ни было - размер и гарнитуру шрифта, не говоря уже о шрифтоначертании или цвете фона.
...
Открытие файла сделано далеко не блестяще - нужно набрать путь либо в командной строке, либо после еле заметной галочки вслед за пунктом меню Load.
..."
Это про xedit. :-) Который умеет C-код "раскрашивать", и вообще,
почти что маленький брат emacs'а.
В общем, вот так вот. :-/
/poige
--
http://www.i.morning.ru/~poige/
| | |
| 1.11, CGen (?), 02:33, 15/06/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Так выходит дело не в USF, а в работе FreeBSD с дисками?
Моё чисто субъективное мнение: 5 CURRENT работает заметно медленнее, чем 4.10. | | |
| |
| 2.12, c0x (?), 08:13, 15/06/2004 [^] [^^] [^^^] [ответить]
| +/– |
>Так выходит дело не в USF, а в работе FreeBSD с дисками?
>
>Моё чисто субъективное мнение: 5 CURRENT работает заметно медленнее, чем 4.10.
Почитайте /usr/src/UPDATING | | |
|
|
