linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Kevin P. Fleming" <kpfleming@backtobasicsmgmt.com>
To: Nathan Scott <nathans@sgi.com>
Cc: Jens Axboe <axboe@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Linux-raid maillist <linux-raid@vger.kernel.org>,
	linux-lvm@sistina.com
Subject: Re: Reproducable OOPS with MD RAID-5 on 2.6.0-test11
Date: Tue, 02 Dec 2003 06:15:24 -0700	[thread overview]
Message-ID: <3FCC906C.5040907@backtobasicsmgmt.com> (raw)
In-Reply-To: <20031202211002.C2009778@wobbly.melbourne.sgi.com>

Nathan Scott wrote:

> One thing that might be of interest - XFS does tend to pass
> variable size requests down to the block layer, and this has
> tripped up md and other drivers in 2.4 in the distant past.
> 
> Log IO is typically 512 byte aligned (as opposed to block or
> page size aligned), as are IOs into several of XFS' metadata
> structures.

Hey, thanks for the pointer! I think we're getting somewhere now. Here's 
a recap of the tested combinations:

XFS on raw disk: OK
XFS on LVM2 on single disk: OK
XFS on LVM2 on RAID-5: fails
ext2 on LVM2 on RAID-5: OK

I just tested XFS on LVM2 on RAID-5 using "-l sunit=8" while creating 
the filesystem to force log writes be block-sized and block-aligned; 
this seems to work :-) I have not been able to force a failure using my 
test script, although ATM the system is still running a RAID-5 resync of 
the array, but that should only make the problem more likely, not less.

So, this does appear to be an md/dm stacking problem, that is exposed by 
XFS sending non-block-sized and/or non-block-aligned IOs.


  reply	other threads:[~2003-12-02 13:15 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-01 14:06 Reproducable OOPS with MD RAID-5 on 2.6.0-test11 Kevin P. Fleming
2003-12-01 14:11 ` Jens Axboe
2003-12-01 14:15   ` Kevin P. Fleming
2003-12-01 15:51     ` Jens Axboe
2003-12-02  4:02       ` Kevin P. Fleming
2003-12-02  4:15         ` Mike Fedyk
2003-12-02 13:11           ` Kevin P. Fleming
2003-12-02  8:27         ` Jens Axboe
2003-12-02 10:10           ` Nathan Scott
2003-12-02 13:15             ` Kevin P. Fleming [this message]
2003-12-03  3:32             ` Nathan Scott
2003-12-03 17:13               ` Linus Torvalds
2003-12-02 18:23           ` Linus Torvalds
2003-12-04  1:12             ` Simon Kirby
2003-12-04  1:23               ` Linus Torvalds
2003-12-04  4:31                 ` Simon Kirby
2003-12-05  6:55                   ` Theodore Ts'o
2003-12-04 20:53                 ` Herbert Xu
2003-12-04 21:06                   ` Linus Torvalds
2003-12-01 23:06   ` Reproducable OOPS with MD RAID-5 on 2.6.0-test11 - with XFS Neil Brown

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=3FCC906C.5040907@backtobasicsmgmt.com \
    --to=kpfleming@backtobasicsmgmt.com \
    --cc=axboe@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-lvm@sistina.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=nathans@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).