https://www.opennet.dev/openforum/vsluhforumID3/3835.html На этот раз - о быстродействии UFS2 на программном RAID (ccd). Измерения проводились для UFS2 и EXT2 на обычных разделах и UFS2 на программном RAID0. Результат - производительность раздела на RAID0 (логическое объединение IDE дисков) значительно выше, но это не заслуга UFS.<br><br>URL: http://unix.ginras.ru/freenotes/test/ufs-and-ccd.html<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=3981<br> https://www.opennet.dev/openforum/vsluhforumID3/3835.html#15 Tue, 15 Jun 2004 11:07:52 GMT &gt;<br>&gt;&gt; И на сколько нам интересна первоначальная задержка?<br>&gt;<br>&gt;Обрати внимание, что продавцы указывают именно скрорость вращения (главный параметр, определяющий задержку), <br>&gt;а не скорость чтения/записи! Да ради снижения задержки производители перешли от <br>&gt;пятидюймовых дисков к трёхдюймовым, потеряв в два с лишним раза площадь <br>&gt;поверхности (и, соответвтсенно, ёмкости)!!! Ну так что же важнее, а? <br>&gt;<br>Это не то, разговор шел именно о важности начала чтения, и если бы это только одно разовое чтение, я бы согласился.<br> <br>&gt;<br>&gt;Есть вещи, которые нельзя выполнять асинхронно - см.выше про "транзакции". <br>&gt;<br><br>Транзакция или важность сохранения порядка записи на диск IMHO не причем.<br>RAID не должен переписывать очереди, он должен баланисровать нагрузку и не давать запрос чтения на диск с самой длинной очередью заданий. Всего лишь - грубо так.<br><br>Что касается параллельной отработки заданий дисками, делящих шину на контроллер (клинический случай), то это уже сделано. Для передачи данных им конечно придеться разобр https://www.opennet.dev/openforum/vsluhforumID3/3835.html#14 Tue, 15 Jun 2004 10:18:54 GMT в обсуждении прошлой истории тестили async + softupdates<br>а я предлагаю async - softupdates<br><br>на операциях с самбой быстрее в три раза (на тех операциях, которые требуют большого количества маленьких файлов) https://www.opennet.dev/openforum/vsluhforumID3/3835.html#13 Tue, 15 Jun 2004 10:04:32 GMT edo:<br>&gt; 1. запрос может уложиться в один блок (т.е. чтение производится только с одного диска)<br><br>Правильно. Я же говорил, что это - тема часа на два, а то и более. Тут мы сталкиваемся с вопросом о быьоре "блока черелования": если чётные секторы логического диска находятся на одном физическом, а чётные на другом (RAID-0 из двух дисков), то при запросе более одного сектора задержка сразу вырастает с полуоборота до двух/третей.<br><br>Предлагаю специалистам (тем, кто считает себя таковыми) решить задачу о выборе оптимального размера "блока черелования".<br><br>Иными словами, на маленьком запросе особой выгоды мы не получим - выгода возможна только на больших запросах - больше, чем оптимальный размер "блока черелования". Для того, чтобы оперировать такими запросами, надо иметь нехилый объём оперативной памяти на борту.<br><br>&gt; 1a. куча мелких запросов достаточно равномерно распредляется между дисками и мы видим фактически уменьшение времени доступа по сравнению с однодисковой системой<br><br>Да - для этого RAID-контроллер долж https://www.opennet.dev/openforum/vsluhforumID3/3835.html#12 Tue, 15 Jun 2004 04:13:31 GMT &gt;Так выходит дело не в USF, а в работе FreeBSD с дисками? <br>&gt;<br>&gt;Моё чисто субъективное мнение: 5 CURRENT работает заметно медленнее, чем 4.10. <br><br>Почитайте /usr/src/UPDATING https://www.opennet.dev/openforum/vsluhforumID3/3835.html#11 Mon, 14 Jun 2004 22:33:40 GMT Так выходит дело не в USF, а в работе FreeBSD с дисками?<br>Моё чисто субъективное мнение: 5 CURRENT работает заметно медленнее, чем 4.10. https://www.opennet.dev/openforum/vsluhforumID3/3835.html#10 Mon, 14 Jun 2004 21:52:50 GMT &gt;А можно поподробнее про "две трети оборота в случае RAID-0"? Что-то мои <br>&gt;доморощенные знания теории вероятности такого вывода не позволяют сделать. <br>&gt;И уж тем более здравый рассудок не позволяет принять того, что "ускорения <br>&gt;ждать не приходится". Зависит исключительно от размера и типа кэша. RAID-5 <br>&gt;например при чтении работает как RAID-0 на N-1 дисках. <br>&gt;И откуда цифра в 200Кб? Размер блоков разный бывает. <br>&gt;Что-то где-то кто-то там, одним словом. <br><br>У теоретиков все так: если практика не сходитсч с теорией, то тем хуже для практики. Забей.<br><br><br> https://www.opennet.dev/openforum/vsluhforumID3/3835.html#9 Mon, 14 Jun 2004 20:53:09 GMT &gt;&gt; RAID-5 например при чтении работает как RAID-0 на N-1 дисках.<br>&gt;<br>&gt;И чем больше дисков, тем больше начальная задержка. <br>&gt;<br>Ну и у задержки есть предел ;-) !<br>И на сколько нам интересна первоначальная задержка? Если только нам делать больще нечего, то пожалуй. Если ввести асинхронность в процесс обмена с дисками, и считаем задачу выполненной после значительного количества найденных и прочитанных блоков самым невезучим диском, то некоторое увеличение начальной задержки не имеет значения. RAID лишь немногим хуже одинночного диска по затратам времени на каждое позиционнирование.<br><br>Raid5 явно увеличит отношение кол-во_позиционирований/кол-во_данных для каждого диска. Если бы удалось ровномерно распределить файловые операции по дискам без RAID, то это было бы эффективней, чем теже дисковые операции с единым блочным устройством на основе обьеденных в RAID дисков. Осталось только найти некий новый способ балансировки нагрузки.<br>А для RAID-а неплохо использовать предварительное чтение, не скупиться на буфера https://www.opennet.dev/openforum/vsluhforumID3/3835.html#8 Mon, 14 Jun 2004 09:17:05 GMT Если этот тот же Федорчук, что и автор<br><br>http://cs.mipt.ru/docs/comp/rus/os/unix/user_guide/fedorchuk/office/2/002xeditors.html<br><br>(http://www.yandex.ru/, искать Федорчук xedit)<br><br>то увы, без скепсиса, к его творениям, мне относиться уже не удается:<br><br>"...<br>Этот редактор - прост, как грабли (или реклама в бозе почившей фирмы Сэлдом). Белый экран с тремя пунктами меню в верхней части (Quit, Save, Load). Ниже - рабочее поле с миниатюрными, совершенно непосильными для моего зрения буквами (рис. 3). Полная невозможность настроить чего бы то ни было - размер и гарнитуру шрифта, не говоря уже о шрифтоначертании или цвете фона.<br><br>...<br>Открытие файла сделано далеко не блестяще - нужно набрать путь либо в командной строке, либо после еле заметной галочки вслед за пунктом меню Load. <br><br>..."<br><br>Это про xedit. :-) Который умеет C-код "раскрашивать", и вообще,<br>почти что маленький брат emacs'а.<br><br>В общем, вот так вот. :-/<br> <br>/poige<br>-- <br>http://www.i.morning.ru/~poige/<br> https://www.opennet.dev/openforum/vsluhforumID3/3835.html#7 Mon, 14 Jun 2004 08:27:56 GMT &gt;&gt; А можно поподробнее про "две трети оборота в случае RAID-0"?<br>&gt;&gt; Что-то мои доморощенные знания теории вероятности такого вывода не позволяют сделать.<br>&gt;<br>&gt;Запрос прихожит в случайное время. Оба диска находятся в случайном положении. Оба <br>&gt;времени ожидания прихода сектора под головку (обозначим их X и Y) <br>&gt;независимы и равномерно распределены в интервале {от 0 до 1}. Нам <br>&gt;нужно максимальное. Берём двойной интергал: <br>&gt;{интеграл от 0 до 1} ( {интеграл от 0 до 1} ( max(X,Y) dX dY ) ) <br>&gt;Дальше брать или не надо? <br><br>1. запрос может уложиться в один блок (то есть чтение производится только с одного диска)<br>1a. куча мелких запросов достаточно равномерно распредляется между дисками и мы видим фактически уменьшение времени доступа по сравнению с однодисковой системой<br>2. блок может быть достаточно большим (то есть за время, пока с первого диска читается блок второй диск ищет следущий - начальное состояние второго диска уже не имеет значения)<br>3. есть raid1. при правильной организации надо брать<br>{интеграл от