public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Stan Hoeppner <stan@hardwarefreak.com>
To: xfs@oss.sgi.com
Subject: Re: failed to read root inode
Date: Sun, 09 May 2010 09:53:55 -0500	[thread overview]
Message-ID: <4BE6CC83.5070305@hardwarefreak.com> (raw)
In-Reply-To: <20100509152818.7481c1e1@galadriel.home>

Emmanuel Florac put forth on 5/9/2010 8:28 AM:
> Le Sat, 08 May 2010 17:53:17 -0500 vous écriviez:
> 
>> Why did the "crash" of a single disk in a hardware RAID6 cause a
>> kernel freeze?  What is your definition of "disk crash"?  A single
>> physical disk failure should not have caused this under any
>> circumstances.  The RAID card should have handled a single disk
>> failure transparently.
> 
> The RAID array may go west if the disk isn't properly set up,
> particularly if it's a desktop-class drive. 

By design, a RAID6 pack should be able to handle two simultaneous drive
failures before the array goes offline.  According to the OP's post he lost
one drive.  Unless it's a really crappy RAID card or if he's using a bunch
of dissimilar drives causing problems with the entire array, he shouldn't
have had a problem.

This is why I'm digging for more information.  The information he presented
here doesn't really make any sense.  One physical disk failure _shouldn't_
have caused the problems he's experiencing.  I don't think we got the full
story.

Oh, btw, when it comes to SATA drives, there is no difference between
"desktop" and "enterprise" class drives.  They're all the same.  The ones
sold as "enterprise" have merely been firmware matched and QC tested with a
given vendor's SAN/NAS box and then certified for use with it.  The vendor
then sells only that one drive/firmware, maybe two certified drives so they
have a second source in case of shortages or price gouging etc, in their arrays.

According to the marketing droids, the only "true" "enterprise" drives
currently on the market are SAS and fiber channel.  The number of these
drives actually shipping into the server/SAN/NAS storage marketplace is
absolutely tiny compared to SATA drives.  In total unit shipments, SATA is
owning the datacenter as well as the desktop.  Browse the various storage
offerings across the big 3 and then 10 of the 2nd tier players and you'll
find at least 8 out of 10 storage arrays are SATA, the remaining two being
SAS and FC in the "high end" category, and usually over double the price of
the SATA based arrays.  This pricing of SAS/FC is what is driving SATA
adoption.  That and really large read/write caches on the SATA arrays
boosting their performance for many workloads and negating the spindle speed
advantage of the SAS and FC drives.

-- 
Stan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2010-05-09 14:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-08 12:34 failed to read root inode Christian Affolter
2010-05-08 15:06 ` Eric Sandeen
2010-05-09 14:53   ` Christian Affolter
2010-05-11 10:05     ` Christian Affolter
2010-05-08 22:53 ` Stan Hoeppner
2010-05-09 13:28   ` Emmanuel Florac
2010-05-09 14:53     ` Stan Hoeppner [this message]
2010-05-09 15:34       ` Emmanuel Florac
2010-05-10  1:09       ` Eric Sandeen
2010-05-09 15:35   ` Christian Affolter
2010-05-09 15:59     ` Emmanuel Florac
2010-05-09 17:34     ` Stan Hoeppner
2010-05-09 18:03 ` Roger Willcocks

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=4BE6CC83.5070305@hardwarefreak.com \
    --to=stan@hardwarefreak.com \
    --cc=xfs@oss.sgi.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox