public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Jim Lawson <jim+linux-kernel@jimlawson.org>,
	linux-kernel@vger.kernel.org,
	Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>,
	Neil Brown <neilb@cse.unsw.edu.au>
Subject: Re: 2.6.0, SiI3112, md raid1 problem: bio too big device (128 > 15)
Date: Wed, 24 Dec 2003 11:47:35 +0100	[thread overview]
Message-ID: <20031224104735.GJ1601@suse.de> (raw)
In-Reply-To: <3FE91EB8.8020107@pobox.com>

On Wed, Dec 24 2003, Jeff Garzik wrote:
> Jim Lawson wrote:
> >Hi all,
> >
> >I am having trouble creating a raid1 array under 2.6.0.  I am able to
> >create raid0 and raid5 mds, but raid1s fail with "bio too big device hde3
> >(128 > 15)", which doesn't tell me a lot.  I can see it's in
> >drivers/block/ll_rw_blk.c, right at the boundary with the device driver,
> >but I'm not enough of a kernel wonk to find out a lot more.
> >
> >I'm not sure if this has to do with a kernel bug, a bug in the driver for
> >the controller I have (SiI3112, Silicon Image 3112), or the disks I am
> >using (Seagate Barracuda 7200.7, 160 GB SATA disks) ... or the combination
> >thereof :-)
> 
> 
> Hum... that's kinda interesting.
> 
> AFAICS, the basic problem is that Silicon Image's sector size limitation 
> means that md cannot submit stripe-sized bio's as it wishes.
> 
> md does indeed split bio's in raid0, so it makes sense that it works (to 
> my naive eye).  I'm amazed raid5 works, since raid5 appears to hardcode 
> STRIPE_SIZE.  And I don't see splitting code in raid1, so it would make 
> sense that raid1 would fail.
> 
> In general though, I'm surprised that each block driver has to 
> reimplement the pain of splitting its own bio's, to conform to the 
> underlying device.  Since bio's can be merged after 
> generic_make_request(), surely it makes sense to implement bio splitting 
> -once- in the block layer, rather than in each block driver that has to 
> care about stackable block devices?

bio splitting _is_ implemented in the block layer, bio_split(). The
restriction is that the bio to be split can only contain one page. The
normal bio buildup makes this easy to guarentee.

We can easily move the actual call to generic_make_request() instead, I
suppose that is what you mean?

-- 
Jens Axboe


  parent reply	other threads:[~2003-12-24 10:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-24  4:37 2.6.0, SiI3112, md raid1 problem: bio too big device (128 > 15) Jim Lawson
2003-12-24  5:06 ` Jeff Garzik
2003-12-24  9:39   ` Andre Hedrick
2003-12-24 10:47   ` Jens Axboe [this message]
2003-12-24 10:51 ` Neil Brown
2003-12-24 18:56   ` Mike Fedyk
2003-12-25  0:27     ` 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=20031224104735.GJ1601@suse.de \
    --to=axboe@suse.de \
    --cc=B.Zolnierkiewicz@elka.pw.edu.pl \
    --cc=jgarzik@pobox.com \
    --cc=jim+linux-kernel@jimlawson.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox