From: Kevin Corry <kevcorry@us.ibm.com>
To: dm-devel@redhat.com
Cc: Joseph Yasi <joe.yasi@gmail.com>
Subject: Re: Re: [PATCH] dm-striped device sizes must be multiple of chunk-size
Date: Fri, 24 Mar 2006 22:46:25 -0600 [thread overview]
Message-ID: <200603242246.25314.kevcorry@us.ibm.com> (raw)
In-Reply-To: <e3538fbd0603222128o525b4608h84b4004fc4ca0a61@mail.gmail.com>
On Wed March 22 2006 11:28 pm, Joseph Yasi wrote:
> I am using the dmraid utility to detect and configure my Intel
> Software Raid RAID0 array. When upgrading to 2.6.16 from 2.6.15, the
> system failed to boot because the device-mapper array was not built.
> I have traced the problem to this patch that limits dm-stripe to
> targets that are multiples of the chunk size. I don't know whether to
> consider this a problem with device-mapper or with the Intel Software
> Raid BIOS that built the array. Dmraid is giving me a target of
> 980460038 blocks with a chunk size of 256 blocks. Is this a problem
> with device-mapper, the dmraid utility or the raid bios? Should
> device-mapper handle striped targets that are not multiples of the
> chunk size?
Hmm...I obviously didn't expect dmraid to be creating such devices.
The kernel patch that was added to 2.6.16 is definitely correct. Dm-stripe
should not allow creating a device with a size that's not a multiple of the
chunk-size. To do so leaves a partial chunk at the end of each device. While
at first glance this might not seem like a big deal, the striping
calculations in the I/O path do not handle this situation (at least, not in
the way you would think it should be handled), and cause I/O errors if you
try to access the end of the stripe device.
> dmesg gives these pertinent lines:
> device-mapper: dm-stripe: Target length not divisible by chunk size.
> device-mapper: error adding target to table.
>
> dmsetup status
> isw_caejhbcidd_Volume03: 0 976173660 linear
> isw_caejhbcidd_Volume02: 0 4209030 linear
> isw_caejhbcidd_Volume01: 0 64197 linear
> isw_caejhbcidd_Volume0: 0 980460038 striped
>
> dmraid -s
> *** Group superset isw_caejhbcidd
> --> Active Subset
> name : isw_caejhbcidd_Volume0
> size : 980460038
> stride : 256
> type : stripe
> status : ok
> subsets: 0
> devs : 2
> spares : 0
In your example, your stripe device is 980460038 sectors, with a 256 sector
chunk-size.This means the stripe device has 3829922 chunks, with 6 sectors
left over (3 on each of the two devices, presumably). I would think that the
BIOS intends that these last 3 sectors on each device should be striped with
an effective chunk-size of 3 sectors. To do this, dmraid should set up a
device with two targets, one with a chunk-size of 256, and one with a
chunk-size of 3. The map would look something like:
0 980460032 striped 2 256 /dev/hda 0 /dev/hdb 0
980460032 6 striped 2 3 /dev/hda /dev/hdb 490230016
Unfortunately, this doesn't work either, because the chunk-size must be a
power-of-2. So...since we know the second target in the map really represents
only one "stripe", we could treat them as a concatenation of independent
linear targets. So we end up with a map like this:
0 980460032 striped 2 256 /dev/hda 0 /dev/hdb 0
980460032 3 linear /dev/hda 490230016
980460032 3 linear /dev/hdb 490230016
I'm thinking that this mapping would do what the BIOS is actually intending.
It ought to be relatively straight-forward to recognize this situation in
dmraid and set up a mapping similar to the one above.
--
Kevin Corry
kevcorry@us.ibm.com
http://www.ibm.com/linux/
http://evms.sourceforge.net/
next prev parent reply other threads:[~2006-03-25 4:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-23 5:28 [PATCH] dm-striped device sizes must be multiple of chunk-size Joseph Yasi
2006-03-25 4:46 ` Kevin Corry [this message]
2006-03-26 0:01 ` Dwaine Garden
2006-03-28 14:06 ` Heinz Mauelshagen
2006-03-28 12:08 ` Heinz Mauelshagen
2006-03-29 13:48 ` Heinz Mauelshagen
2006-03-28 12:15 ` Heinz Mauelshagen
-- strict thread matches above, loose matches on Subject: below --
2006-05-30 13:14 Peyrotau Yannick
2006-06-01 10:18 ` Dwaine Garden
2006-05-31 16:17 Peyrotau Yannick
2006-05-31 23:28 ` Heinz Mauelshagen
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=200603242246.25314.kevcorry@us.ibm.com \
--to=kevcorry@us.ibm.com \
--cc=dm-devel@redhat.com \
--cc=joe.yasi@gmail.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 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.