|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Alexandr S. Agranovsky 2:5020/400 07 Nov 2002 23:11:29
To : Igor Ushkalo
Subject : Re: Re: [Q] AcceleRAID 352 SuSE 7.3
--------------------------------------------------------------------------------
Hi, Igor Ushkalo
IU> ASA> Эти??? Чем же они хорошие? Мне эта вещь не понравилась
IU> ASA> (некоему Sergey V. Matrakshin из RU.UNIX.LINUX - тоже,
IU> ASA> и я с ним согласен, бо щупал эту железяку).
IU> У меня под Unixware эти железяки работают как папы карло
IU> и я доволен... а чем они тебе не понравились-то?
Я у них мониторинга нормального не заметил, под линухом. То
есть, для выяснения текущего статуса (не полетел ли какой винт)
надо либо бежать и смотреть на сервер, либо запускать
curses-based конфигурялку и своими руками продираться через
менюшку.
Кроме того, на RAID5 фактическое чтение - 20Мб/с, а запись
большого файла на конфигурации из трех дисков - всего-то 2Мб/с,
чему я несказанно удивляюсь - если пошел большой кусок
информации, больше, чем 2*число_дисков*размер_блока, то хотя бы
средние блоки этой информации могут писаться с полной скоростью
записи винтов - сразу все блоки враз вместе с их контрольной
суммой (без чтения того, что раньше было), т.е. должно было
получаться не менее 10Мб/с.
Смотри:
Диск1 Диск2 Диск3
1 2 C1
C2 3 4
5 C3 6
7 8 C4
Если контроллер обнаружил, что его просят записать кусок
информации, который пойдет на блоки N2,3,4,5,6,7 - то только для
блока 2 (и 7, схема аналогичная) может понадобиться прочитать 1
(или 2), C1, пересчитать C1 и записать 2 и C1. Для блоков 3 и 4
можно одновременно записать C2, 3 и 4 без чтения того, что
раньше там было.
Я, правда, не уверен, есть ли в природе оптимизация подобного
рода, но она была бы логична на уровне контроллера при
минимальной поддержке со стороны дравйера.
- ---
Alexandr S. Agranovsky llb@udmnet.ru
--- ifmail v.2.15dev5
* Origin: LLB, LLC (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
