All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Reiser <reiser@namesys.com>
To: Neil Brown <neilb@cse.unsw.edu.au>
Cc: Mike Fedyk <mfedyk@matchmail.com>, linux-kernel@vger.kernel.org
Subject: Re: Define conflict between ext3 and raid patches against 2.2.19
Date: Tue, 02 Oct 2001 01:17:55 +0400	[thread overview]
Message-ID: <3BB8DD83.96B9220F@namesys.com> (raw)
In-Reply-To: <20010916155835.C24067@mikef-linux.matchmail.com> <15271.11056.810538.66237@notabene.cse.unsw.edu.au> <20010919133811.B22773@mikef-linux.matchmail.com> <15273.7576.395258.345452@notabene.cse.unsw.edu.au>

More precisely, as long as you understand that resync requires doing the resync
offline,  and
accept that, and remember it, and your colleagues at work remember it:-), you
can use it.  Personally, I would just go to 2.4 myself.

Hans


Neil Brown wrote:
> 
> On Wednesday September 19, mfedyk@matchmail.com wrote:
> > On Tue, Sep 18, 2001 at 09:08:32PM +1000, Neil Brown wrote:
> > >
> > > You should be aware that ext3 (and other journalling filesystems) do
> > > not work reliably over RAID1 or RAID5 in 2.2.  Inparticular, you can
> > > get problems when the array is rebuilding/resyncing.
> > >
> > > But if you only plan to use ext3 with raid0 or linear, you should be
> > > fine.
> > >
> >
> > Can you point me to an archive that describes how to trigger this bug?
> >
> > Was it in linux-raid or ext3-users or ...?
> >
> > Mike
> 
> I don't remember exactly where or when I read it - either linux-raid
> or linux-kernel.  It was asserted by Stephen Tweedie.
> 
> The problem is that ext3 is very careful about when it writes buffer
> to disk : it won't release a buffer until the relevant journal entry
> is committed.
> 
> However when a RAID rebuild happens, every block on the array is read
> into the buffer cache (if it isn't already there) and then written
> back out again.  This defeats the control that ext3 tries to maintain
> on the buffer cache.
> 
> I don't know exactly what large-scale effects this might have.  It
> could be simply that a crash at the wrong time could leave the
> filesystem corrupted.  But I heard of one person who claimed to get
> filesystem corruption after using reiserfs over RAID1 in 2.2, so maybe
> it's worse than that.
> 
> If you really need to know, I suggest you ask on ext3-users.
> 
> NeilBrown
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

      parent reply	other threads:[~2001-10-01 21:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-16 22:58 Define conflict between ext3 and raid patches against 2.2.19 Mike Fedyk
2001-09-16 23:09 ` Lehmann 
2001-09-17  1:43   ` Mike Fedyk
2001-09-17  4:42     ` Andreas Dilger
2001-09-18 11:08 ` Neil Brown
2001-09-18 19:24   ` Mike Fedyk
2001-09-19 20:38   ` Mike Fedyk
2001-09-19 22:35     ` Neil Brown
2001-09-21 13:10       ` Stephen C. Tweedie
2001-09-21 22:44         ` Mike Fedyk
2001-10-01 21:17       ` Hans Reiser [this message]

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=3BB8DD83.96B9220F@namesys.com \
    --to=reiser@namesys.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mfedyk@matchmail.com \
    --cc=neilb@cse.unsw.edu.au \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.