From: Pallai Roland <dap@mail.index.hu>
To: David Chinner <dgc@sgi.com>
Cc: Linux-Raid <linux-raid@vger.kernel.org>, xfs@oss.sgi.com
Subject: Re: raid5: I lost a XFS file system due to a minor IDE cable problem
Date: Fri, 25 May 2007 16:01:27 +0200 [thread overview]
Message-ID: <200705251601.27577.dap@mail.index.hu> (raw)
In-Reply-To: <1180056948.6183.10.camel@daptopfc.localdomain>
On Friday 25 May 2007 03:35:48 Pallai Roland wrote:
> On Fri, 2007-05-25 at 10:05 +1000, David Chinner wrote:
> > On Thu, May 24, 2007 at 07:20:35AM -0400, Justin Piszcz wrote:
> > > On Thu, 24 May 2007, Pallai Roland wrote:
> > > >It's a good question too, but I think the md layer could
> > > >save dumb filesystems like XFS if denies writes after 2 disks are
> > > > failed, and
> > > >I cannot see a good reason why it's not behave this way.
> >
> > How is *any* filesystem supposed to know that the underlying block
> > device has gone bad if it is not returning errors?
>
> It is returning errors, I think so. If I try to write raid5 with 2
> failed disks with dd, I've got errors on the missing chunks.
> The difference between ext3 and XFS is that ext3 will remount to
> read-only on the first write error but the XFS won't, XFS only fails
> only the current operation, IMHO. The method of ext3 isn't perfect, but
> in practice, it's working well.
Sorry, I was wrong: md really isn't returning error! It's madness, IMHO.
The reason why ext3 safer on raid5 in practice is that ext3 remounts to
read-only on read errors too and when a raid5 array got 2 failed drives and
there's some read, the error= behavior of ext3 will be activated and stops
further writes. You're right, it's not a good solution and there should be
read operations to prevent data loss in this case on ext3 too. Raid5 *must
deny all writes* when 2 disks failed: I still can't see a good reason why
not, and the current method is braindead!
> > I did mention this exact scenario in the filesystems workshop back
> > in february - we'd *really* like to know if a RAID block device has gone
> > into degraded mode (i.e. lost a disk) so we can throttle new writes
> > until the rebuil dhas been completed. Stopping writes completely on a
> > fatal error (like 2 lost disks in RAID5, and 3 lost disks in RAID6)
> > would also be possible if only we could get the information out
> > of the block layer.
Yes, it's sounds good, but I think we need a quick fix now, it's a real
problem and easily can lead to mass data loss.
--
d
next prev parent reply other threads:[~2007-05-25 14:01 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-24 11:18 raid5: I lost a XFS file system due to a minor IDE cable problem Pallai Roland
2007-05-24 11:20 ` Justin Piszcz
2007-05-25 0:05 ` David Chinner
2007-05-25 1:35 ` Pallai Roland
2007-05-25 4:55 ` David Chinner
2007-05-25 5:43 ` Alberto Alonso
2007-05-25 8:36 ` David Chinner
2007-05-28 22:45 ` Alberto Alonso
2007-05-29 3:28 ` David Chinner
2007-05-29 3:37 ` Alberto Alonso
2007-05-25 14:35 ` Pallai Roland
2007-05-28 0:30 ` David Chinner
2007-05-28 1:50 ` Pallai Roland
2007-05-28 2:17 ` David Chinner
2007-05-28 11:17 ` Pallai Roland
2007-05-28 23:06 ` David Chinner
2007-05-25 14:01 ` Pallai Roland [this message]
2007-05-28 12:53 ` Pallai Roland
2007-05-28 15:30 ` Pallai Roland
2007-05-28 23:36 ` David Chinner
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=200705251601.27577.dap@mail.index.hu \
--to=dap@mail.index.hu \
--cc=dgc@sgi.com \
--cc=linux-raid@vger.kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).