[CentOS] 8-15 TB storage: any recommendations?
cap at nsc.liu.se
Wed Jan 13 10:43:35 UTC 2010
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")
> 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: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.centos.org/pipermail/centos/attachments/20100113/6592f634/attachment.bin
More information about the CentOS