From: Michael Shigorin <mike@osdn.org.ua> To: hardware@lists.altlinux.org Subject: [Hardware] Fwd: Re: Q: inexpensive Software RAID setup Date: Fri, 27 Apr 2007 14:33:29 +0300 Message-ID: <20070427113329.GV27825@osdn.org.ua> (raw) ----- Forwarded message from Serge Ryabchun <serge.ryabchun/gmail.com> ----- Date: Fri, 27 Apr 2007 14:19:15 +0300 From: "Serge Ryabchun" <serge.ryabchun/gmail.com> To: "Dmitry V. Levin" <ldv/altlinux.org> Subject: Re: [Hardware] Q: inexpensive Software RAID setup Cc: "Michael Shigorin" <mike/altlinux.ru> 27.04.07, Dmitry V. Levin <ldv/altlinux.org> написал(а): >On Thu, Apr 26, 2007 at 02:54:36PM +0300, Michael Shigorin wrote: >> On Wed, Apr 25, 2007 at 03:51:19AM +0400, Dmitry V. Levin wrote: >> > > 2 ldv: не бери Seagate 7200.9 ни за какие коврижки, у них >> > > reportedly тонкие крышки -- 400Gb застучал сразу, один из >> > > двух 200Gb (другого вендора год тому не выходило) -- через >> > > неделю начал жаловаться в SMART. На WD и Hitachi нареканий >> > > пока нет, для FTP лучше хитачи -- у них seek заметно лучше >> > > оптимизирован, хотя линейное чтение несколько меньше (заметно >> > > меньше для 400-к, по словам sr@). >> > Вопрос из другой оперы, но раз уж зашёл разговор: >> > Имеются ли возражения против ST3750640NS? >> > (планируется под raid10 из 4*750) возражений нет, но если есть возможность, то попробуйте отобрать диски с разлетом в показателях не больше 1%. Практика показывает, что из десятка дисков 1-3 имеют вылет средних значений на 5-10% и они же являются первыми кандидатами на выход со строя. >> >> Может быть проще засунуть 8*400/320 в отдельный корпус 2--3U >> как raid50 или пару raid5. > >Корпус 1U не растягивается до 2-3U, да и оплата за colocation >начисляется пропорционально U. > >> Очень не хочется верить экстремальным на данный момент дискам. > >Через полгода-год эти диски уже не будут казаться экстремальными. > >> sr@ на мой вопрос о raid10 отзывался неодобрительно о его >> производительности -- > >raid10 заведомо производительнее raid5. по записи они практически одинаковы - скорость записи одного диска по определению, при большом количестве дисков raid5 проваливается ниже изза read-write на записи вместо просто write на мелких порциях, просто не хватает процессора-шины. на 2.6.18 при писателях больше одного проваливаются оба одинаково хорошо. На чтении raid5 давал где-то (X-1.5)*R, где X к-во дисков, R скорость чтения диска на данном участке. Те в начале диска 75MB/s и RAID5 на 4 диска выдавал порядка 180-190, при нескольких читателях падение до 100-130, при наличии писателей еще ниже. При этом RAID10 вел себя вообще непредсказуемо и поваливался до 80-90. Ессейсно, данные точные где-то остались, но помоему только на бумаге в институте, мерялось все на набортных AHCI на вудкристах в 64bit режиме, другая платформа вполне может дать другие результаты, другие ядра аналогично. Оптимальным выходит использование RAID1, запись 1*W, чтение 1.9*R на один массив. Чтение одним читателем не масштабируется, те при одном читателе имеем 1*R. Правда, использование везде RAID1 у меня связано еще и с невозможностью сейчас заюзать софтовый RAID5 в LUSTRE, в некоторых ситуациях LUSTRE умудряется изменить данные в страйпе без пересчета контрольной суммы с последующим развалом данных. Патчи для исправления есть только для ядер времен царя гороха и они совсем не тривиальные. >> если у суппорта есть время собрать десятый >> и пятый и проверить, тоже был бы благодарен. > >Аналогично, хотя ответ мне известен заранее. Не уверен, RAID10 в linux на 2.6.18 давал результаты хуже, чем RAID10 на ареке, что очень подозрительно хотя бы потому, что какой-то интеловский 500MHz risc гороздо медленнее i5140 и 256MB DDR266 кеша гораздо хуже 4GB FB-DIMM. Вобщем, даже если RAID10 в линухе будет или уже поправлен, то у меня все-равно на ближайшие пару лет "впечатление осталось". ----- End forwarded message ----- -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/
reply other threads:[~2007-04-27 11:33 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20070427113329.GV27825@osdn.org.ua \ --to=mike@osdn.org.ua \ --cc=hardware@lists.altlinux.org \ --cc=shigorin@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux hardware support This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/hardware/0 hardware/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 hardware hardware/ http://lore.altlinux.org/hardware \ hardware@altlinux.ru hardware@lists.altlinux.org hardware@lists.altlinux.ru hardware@lists.altlinux.com hardware@altlinux.org public-inbox-index hardware Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.hardware AGPL code for this site: git clone https://public-inbox.org/public-inbox.git