Define conflict between ext3 and raid patches against 2.2.19

Define conflict between ext3 and raid patches against 2.2.19

[Mike Fedyk]

Hi,

I'm trying to setup a 2.2 kernel that I can use for comparison to the latest
2.4 kernels I've been testing, but I came accross a little problem with the
patches I've been trying to combine.

I've already applied:
ide.2.2.19.05042001.patch
linux-2.2.19.kdb.diff
linux-2.2.19.ext3.diff

And now I'm trying to apply raid-2.2.19-A1, and I get one reject in
include/linux/fs.h.

***************
*** 191,197 ****
  #define BH_Req		3	/* 0 if the buffer has been invalidated */
  #define BH_Protected	6	/* 1 if the buffer is protected */
  #define BH_Wait_IO	7	/* 1 if we should throttle on this buffer */

  /*
   * Try to keep the most commonly used fields in single cache lines (16
--- 191,196 ----
  #define BH_Req		3	/* 0 if the buffer has been invalidated */
  #define BH_Protected	6	/* 1 if the buffer is protected */
  #define BH_Wait_IO	7	/* 1 if we should throttle on this buffer */
+ #define BH_LowPrio	8	/* 1 if the buffer is lowprio */
  
  /*
   * Try to keep the most commonly used fields in single cache lines (16

Now I have two defines from different patches for the same bit.  The top
line is from RAID, and bottom is of ext3 origin.

#define BH_LowPrio	8	/* 1 if the buffer is lowprio */
#define BH_Temp         8       /* 1 if the buffer is temporary (unlinked)

Is this a fatal conflict?  How can I resolve this?

Mike

Re: Define conflict between ext3 and raid patches against 2.2.19

[Lehmann]

On Sun, Sep 16, 2001 at 03:58:35PM -0700, Mike Fedyk <mfedyk@matchmail.com> wrote:
> #define BH_LowPrio	8	/* 1 if the buffer is lowprio */
> #define BH_Temp         8       /* 1 if the buffer is temporary (unlinked)

Change BH_Temp to:

#define BH_Temp         9       /* 1 if the buffer is temporary (unlinked)

and it should work.
                                     
-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: Define conflict between ext3 and raid patches against 2.2.19

[Mike Fedyk]

On Mon, Sep 17, 2001 at 01:09:27AM +0200,  Marc A. Lehmann  wrote:
> On Sun, Sep 16, 2001 at 03:58:35PM -0700, Mike Fedyk <mfedyk@matchmail.com> wrote:
> > #define BH_LowPrio	8	/* 1 if the buffer is lowprio */
> > #define BH_Temp         8       /* 1 if the buffer is temporary (unlinked)
> 
> Change BH_Temp to:
> 
> #define BH_Temp         9       /* 1 if the buffer is temporary (unlinked)
> 
> and it should work.
>                                      

/* bh state bits */
#define BH_Uptodate     0       /* 1 if the buffer contains valid data */
#define BH_Dirty        1       /* 1 if the buffer is dirty */
#define BH_Lock         2       /* 1 if the buffer is locked */
#define BH_Req          3       /* 0 if the buffer has been invalidated */
#define BH_Protected    6       /* 1 if the buffer is protected */
#define BH_Wait_IO      7       /* 1 if we should throttle on this buffer */
#define BH_Temp         8       /* 1 if the buffer is temporary (unlinked) */
#define BH_JWrite       9       /* 1 if being written to log (@@@ DEBUGGING)*/
#define BH_QuickFree    10      /* 1 if alloced and freed quickly (see below)*/
#define BH_Alloced      11      /* 1 if buffer has been allocated */
#define BH_Freed        12      /* 1 if buffer has been freed (truncated)*/
#define BH_Revoked      13      /* 1 if buffer has been revoked from the log*/
#define BH_RevokeValid  14      /* 1 if buffer revoked flag is valid */
#define BH_JDirty       15      /* 1 if buffer is dirty but journaled */

As you can see, that is already taken from ext3.  Is this ok?

#define BH_LowPrio      16      /* 1 if the buffer is temporary (unlinked)

Or do I only have 16 bits to work with?

TIA,

Mike

Re: Define conflict between ext3 and raid patches against 2.2.19

[Andreas Dilger]

On Sep 16, 2001  18:43 -0700, Mike Fedyk wrote:
> > Change BH_Temp to:
> > 
> > #define BH_Temp         9       /* 1 if the buffer is temporary (unlinked)
> > 
> > and it should work.
> >                                      
> 
> /* bh state bits */
> #define BH_Uptodate     0       /* 1 if the buffer contains valid data */
> #define BH_Dirty        1       /* 1 if the buffer is dirty */
> #define BH_Lock         2       /* 1 if the buffer is locked */
> #define BH_Req          3       /* 0 if the buffer has been invalidated */
> #define BH_Protected    6       /* 1 if the buffer is protected */
> #define BH_Wait_IO      7       /* 1 if we should throttle on this buffer */
> #define BH_Temp         8       /* 1 if the buffer is temporary (unlinked) */
> #define BH_JWrite       9       /* 1 if being written to log (@@@ DEBUGGING)*/
> #define BH_QuickFree    10      /* 1 if alloced and freed quickly (see below)*/
> #define BH_Alloced      11      /* 1 if buffer has been allocated */
> #define BH_Freed        12      /* 1 if buffer has been freed (truncated)*/
> #define BH_Revoked      13      /* 1 if buffer has been revoked from the log*/
> #define BH_RevokeValid  14      /* 1 if buffer revoked flag is valid */
> #define BH_JDirty       15      /* 1 if buffer is dirty but journaled */
> 
> As you can see, that is already taken from ext3.  Is this ok?
> 
> #define BH_LowPrio      16      /* 1 if the buffer is temporary (unlinked)
> 
> Or do I only have 16 bits to work with?

No, you have 32 bits to work with.  In my ext3-2.2 patches I just increased
all of the ext3 numbers by one.  I don't think it is critical what number is
used in the end, as long as you don't get another patch defining these flags
(reiserfs uses these flags in 2.2 as well).

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: Define conflict between ext3 and raid patches against 2.2.19

[Neil Brown]

On Sunday September 16, mfedyk@matchmail.com wrote:
> Hi,
> 
> I'm trying to setup a 2.2 kernel that I can use for comparison to the latest
> 2.4 kernels I've been testing, but I came accross a little problem with the
> patches I've been trying to combine.
> 
> I've already applied:
> ide.2.2.19.05042001.patch
> linux-2.2.19.kdb.diff
> linux-2.2.19.ext3.diff
> 
> And now I'm trying to apply raid-2.2.19-A1, and I get one reject in
> include/linux/fs.h.

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.

NeilBrown

Re: Define conflict between ext3 and raid patches against 2.2.19

[Mike Fedyk]

 On Tue, Sep 18, 2001 at 09:08:32PM +1000, Neil Brown wrote:
> On Sunday September 16, mfedyk@matchmail.com wrote:
> > Hi,
> > 
> > I'm trying to setup a 2.2 kernel that I can use for comparison to the latest
> > 2.4 kernels I've been testing, but I came accross a little problem with the
> > patches I've been trying to combine.
> > 
> > I've already applied:
> > ide.2.2.19.05042001.patch
> > linux-2.2.19.kdb.diff
> > linux-2.2.19.ext3.diff
> > 
> > And now I'm trying to apply raid-2.2.19-A1, and I get one reject in
> > include/linux/fs.h.
> 
> 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.
> 

Crap.

I was just about to test ext3 on a raid1 with 2.2.20pre.  Everything else
I've tried has worked great.

As it looks, this probably won't be fixed in 2.2, especially since the raid
patch won't be merged into 2.2 (as stated by Alan).

I'll just have to test 2.4 harder now.  2.4.x-ac has been pretty good
concerning swap usage, and performance on my workstations.  I hope 2.4.10
will merge those improvements.

Mike

Re: Define conflict between ext3 and raid patches against 2.2.19

[Mike Fedyk]

On Tue, Sep 18, 2001 at 09:08:32PM +1000, Neil Brown wrote:
> On Sunday September 16, mfedyk@matchmail.com wrote:
> > Hi,
> > 
> > I'm trying to setup a 2.2 kernel that I can use for comparison to the latest
> > 2.4 kernels I've been testing, but I came accross a little problem with the
> > patches I've been trying to combine.
> > 
> > I've already applied:
> > ide.2.2.19.05042001.patch
> > linux-2.2.19.kdb.diff
> > linux-2.2.19.ext3.diff
> > 
> > And now I'm trying to apply raid-2.2.19-A1, and I get one reject in
> > include/linux/fs.h.
> 
> 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

Re: Define conflict between ext3 and raid patches against 2.2.19

[Neil Brown]

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

Re: Define conflict between ext3 and raid patches against 2.2.19

[Stephen C. Tweedie]

Hi,

On Thu, Sep 20, 2001 at 08:35:04AM +1000, Neil Brown wrote:

> 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.

Immediately after a crash, the fs will be OK.  But during the
subsequent background raid reconstruction, it can get out of sync
again.  This can result in silent data loss in some cases, but it is
also likely to trigger some internal ext3 debugging which detects
out-of-order data writes, resulting in a kernel panic.

Cheers,
 Stephen

Re: Define conflict between ext3 and raid patches against 2.2.19

[Mike Fedyk]

On Fri, Sep 21, 2001 at 02:10:50PM +0100, Stephen C. Tweedie wrote:
> Hi,
> 
> On Thu, Sep 20, 2001 at 08:35:04AM +1000, Neil Brown wrote:
> 
> > 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.
> 
> Immediately after a crash, the fs will be OK.  But during the
> subsequent background raid reconstruction, it can get out of sync
> again.  This can result in silent data loss in some cases, but it is
> also likely to trigger some internal ext3 debugging which detects
> out-of-order data writes, resulting in a kernel panic.
> 

Ok, thanks guys, on ext3-users and lkml.

Now I know that if I want RAID1 or RAID5 with ext3, I'm going to need 2.4...

Test test test...

Mike

Re: Define conflict between ext3 and raid patches against 2.2.19

[Hans Reiser]

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/