On Wednesday 13 January 2010, Pasi Kärkkäinen wrote: > On Wed, Jan 13, 2010 at 01:05:39AM +0100, Peter Kjellstrom wrote: > > On Tuesday 12 January 2010, Les Mikesell wrote: > > > On 1/12/2010 10:39 AM, Peter Kjellstrom wrote: > > > > ... > > > > > >>> ...that said, it's not much worse than the competetion, storage > > > >>> simply sucks ;-( > > > >> > > > >> So you are saying people dole out huge amounts of money for rubbish? > > > >> That the software raid people were and have always been right? > > > > > > > > Nope, storage sucks, that includes the software ;-) > > > > > > If you can split the storage up into 2TB or smaller volumes that you > > > can mount into sensible locations to spread the load and avoid > > > contention you can always use software RAID1. > > > > Funny you should mention software RAID1... I've seen two instances of > > that getting silently out-of-sync and royally screwing things up beyond > > all repair. > > > > Maybe this thread has gone on long enough now? > > Not yet :) > > Please tell more about your hardware and software. What distro? What > kernel? What disk controller? What disks? Both of my data-points are several years old so most of the details are lost in the fog-of-lost-memories... Both were on desktop class hardware with onboard IDE or SATA. If I remember correctly one was on CentOS(4?) and one was on either an old Ubuntu or a classic debian (atleast we're talking 2.6 kernels). My main point was that, nope, linux-md is not the holy grail either. The only storage products that I've not had fail me tend to be either: 1) Those that are too new (give them time) 2) Those that I havn't tried (in scale) yet (which always gives a strong "the grass is greener on the other side feeling") /Peter > I'm interested in this because I have never seen Linux software MD RAID1 > failures like this, but some people keep telling they happen frequently.. > > I'm just wondering why I'm not seeing these failures, or if I've just > been lucky so far.. > > -- Pasi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: <http://lists.centos.org/pipermail/centos/attachments/20100113/6592f634/attachment-0005.sig>