From: Neil Brown <neilb@suse.de>
To: Milan Broz <mbroz@redhat.com>
Cc: "Marti Raudsepp" <marti@juffo.org>,
"Ing. Daniel Rozsnyó" <daniel@rozsnyo.com>,
linux-kernel@vger.kernel.org
Subject: Re: bio too big - in nested raid setup
Date: Thu, 28 Jan 2010 13:28:12 +1100 [thread overview]
Message-ID: <20100128132812.2d01f211@notabene> (raw)
In-Reply-To: <4B5DE2A9.4030500@redhat.com>
On Mon, 25 Jan 2010 19:27:53 +0100
Milan Broz <mbroz@redhat.com> wrote:
> On 01/25/2010 04:25 PM, Marti Raudsepp wrote:
> > 2010/1/24 "Ing. Daniel Rozsnyó" <daniel@rozsnyo.com>:
> >> Hello,
> >> I am having troubles with nested RAID - when one array is added to the
> >> other, the "bio too big device md0" messages are appearing:
> >>
> >> bio too big device md0 (144 > 8)
> >> bio too big device md0 (248 > 8)
> >> bio too big device md0 (32 > 8)
> >
> > I *think* this is the same bug that I hit years ago when mixing
> > different disks and 'pvmove'
> >
> > It's a design flaw in the DM/MD frameworks; see comment #3 from Milan Broz:
> > http://bugzilla.kernel.org/show_bug.cgi?id=9401#c3
>
> Hm. I don't think it is the same problem, you are only adding device to md array...
> (adding cc: Neil, this seems to me like MD bug).
>
> (original report for reference is here http://lkml.org/lkml/2010/1/24/60 )
No, I think it is the same problem.
When you have a stack of devices, the top level client needs to know the
maximum restrictions imposed by lower level devices to ensure it doesn't
violate them.
However there is no mechanism for a device to report that its restrictions
have changed.
So when md0 gains a linear leg and so needs to reduce the max size for
requests, there is no way to tell DM, so DM doesn't know. And as the
filesystem only asks DM for restrictions, it never finds out about the
new restrictions.
This should be fixed by having the filesystem not care about restrictions,
and the lower levels just split requests as needed, but that just hasn't
happened....
If you completely assemble md0 before activating the LVM stuff on top of it,
this should work.
NeilBrown
next prev parent reply other threads:[~2010-01-28 2:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-24 18:49 bio too big - in nested raid setup "Ing. Daniel Rozsnyó"
2010-01-25 15:25 ` Marti Raudsepp
2010-01-25 18:27 ` Milan Broz
2010-01-28 2:28 ` Neil Brown [this message]
2010-01-28 9:24 ` "Ing. Daniel Rozsnyó"
2010-01-28 10:50 ` Neil Brown
2010-01-28 12:07 ` Boaz Harrosh
2010-01-28 22:14 ` Neil Brown
2010-01-31 15:42 ` Boaz Harrosh
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=20100128132812.2d01f211@notabene \
--to=neilb@suse.de \
--cc=daniel@rozsnyo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marti@juffo.org \
--cc=mbroz@redhat.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