"bio too big" error

"bio too big" error

[Wil Reichert]

Hi,

I'm getting a "bio too big" error with 2.5.50.  I've got a 330G lvm2
partition formatted with ext3 using the -T largefile4 parameter. 
Everything seems ok at first, but any sort of access will die very
unhappily with said error messsage after about 10 seconds of operation
or so.  The only google search results are the patch submission.  Eeek.

Wil

Re: "bio too big" error

[Andrew Morton]

Wil Reichert wrote:
> 
> Hi,
> 
> I'm getting a "bio too big" error with 2.5.50.  I've got a 330G lvm2
> partition formatted with ext3 using the -T largefile4 parameter.
> Everything seems ok at first, but any sort of access will die very
> unhappily with said error messsage after about 10 seconds of operation
> or so.  The only google search results are the patch submission.  Eeek.
> 

How odd.

Please send the full diagnostic output.

And add this:


--- 25/drivers/block/ll_rw_blk.c~a	Tue Dec 10 18:42:54 2002
+++ 25-akpm/drivers/block/ll_rw_blk.c	Tue Dec 10 18:43:13 2002
@@ -1921,6 +1921,7 @@ end_io:
 			       bdevname(bio->bi_bdev),
 			       bio_sectors(bio),
 			       q->max_sectors);
+			dump_stack();
 			goto end_io;
 		}
 

_

Re: "bio too big" error

[Wil Reichert]

Exact error with debug is:

darwin:/a01/mp3s/Skinny Puppy/Too Dark Park# ogg123 -q 01\ -\
Convulsion.ogg
bio too big device ide0(3,4) (256 > 255)
Call Trace: [<c020055e>]  [<e09ff46d>]  [<e09ff558>]  [<e09ff5f5>] 
[<c020050a>]  [<c02005f4>]  [<c017048e>]  [<c0170a79>]  [<c0187770>] 
[<c01472e6>]  [<c0187770>]  [<c0140edd>]  [<c01977fc>]  [<c01473e4>] 
[<c01475be>]  [<c0137ac8>]  [<c0137e60>]  [<c0138124>]  [<c0137e60>] 
[<c01381ca>]  [<c014eadb>]  [<c01094cb>]
[<e09def98>]  [<c01113bf>]  [<c0110ac2>]  [<c014ebce>]  [<c014ee6e>] 
[<c010967f>]

I'm guessing its perhaps a 2.5 / lvm issue?  Here's 'vgdisplay -v' in
case:

    Finding all volume groups
    Finding volume group "cheese_vg"
  --- Volume group ---
  VG Name               cheese_vg
  System ID             darwin1025684717
  Format                lvm2
  Metadata Areas        6
  Metadata Sequence No  1
  VG Access             read/write
  VG Status             resizable
  MAX LV                256
  Cur LV                1
  Open LV               1
  Max PV                256
  Cur PV                5
  Act PV                5
  VG Size               330.05 GB
  PE Size               16.00 MB
  Total PE              21123
  Alloc PE / Size       21123 / 330.05 GB
  Free  PE / Size       0 / 0
  VG UUID               WF3vAx-k1r3-NUjU-az7z-I4SM-oorx-rvoYSt
   
  --- Logical volume ---
  LV Name                /dev/cheese_vg/blah
  VG Name                cheese_vg
  LV UUID                000000-0000-0000-0000-0000-0000-000000
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                330.05 GB
  Current LE             21123
  Segments               7
  Allocation             next free
  Read ahead sectors     1024
  Block device           254:0
   
  --- Physical volumes ---
  PV Name               /dev/discs/disc1/disc     
  PV Status             allocatable
  Total PE / Free PE    4769 / 0
   
  PV Name               /dev/ide/host2/bus0/target0/lun0/disc     
  PV Status             allocatable
  Total PE / Free PE    7361 / 0
   
  PV Name               /dev/ide/host2/bus1/target0/lun0/disc     
  PV Status             allocatable
  Total PE / Free PE    5961 / 0
   
  PV Name               /dev/discs/disc0/part4     
  PV Status             allocatable
  Total PE / Free PE    2431 / 0
   
  PV Name               /dev/discs/disc4/disc     
  PV Status             allocatable
  Total PE / Free PE    601 / 0


Wil

On Tue, 2002-12-10 at 21:44, Andrew Morton wrote:
> Wil Reichert wrote:
> > 
> > Hi,
> > 
> > I'm getting a "bio too big" error with 2.5.50.  I've got a 330G lvm2
> > partition formatted with ext3 using the -T largefile4 parameter.
> > Everything seems ok at first, but any sort of access will die very
> > unhappily with said error messsage after about 10 seconds of operation
> > or so.  The only google search results are the patch submission.  Eeek.
> > 
> 
> How odd.
> 
> Please send the full diagnostic output.
> 
> And add this:
> 
> 
> --- 25/drivers/block/ll_rw_blk.c~a	Tue Dec 10 18:42:54 2002
> +++ 25-akpm/drivers/block/ll_rw_blk.c	Tue Dec 10 18:43:13 2002
> @@ -1921,6 +1921,7 @@ end_io:
>  			       bdevname(bio->bi_bdev),
>  			       bio_sectors(bio),
>  			       q->max_sectors);
> +			dump_stack();
>  			goto end_io;
>  		}
>  
> 
> _
> -
> 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/
-- 
Wil Reichert <wilreichert@yahoo.com>

Re: "bio too big" error

[Greg KH]

On Tue, Dec 10, 2002 at 10:38:58PM -0500, Wil Reichert wrote:
> 
> I'm guessing its perhaps a 2.5 / lvm issue?  Here's 'vgdisplay -v' in
> case:

Did you try the dm patches that were just posted to lkml today?

thanks,

greg k-h

Re: "bio too big" error

[Andrew Morton]

Wil Reichert wrote:
> 
> Exact error with debug is:
> 
> darwin:/a01/mp3s/Skinny Puppy/Too Dark Park# ogg123 -q 01\ -\
> Convulsion.ogg
> bio too big device ide0(3,4) (256 > 255)
> Call Trace: [<c020055e>]  [<e09ff46d>]  [<e09ff558>]  [<e09ff5f5>]
> [<c020050a>]  [<c02005f4>]  [<c017048e>]  [<c0170a79>]  [<c0187770>]
> [<c01472e6>]  [<c0187770>]  [<c0140edd>]  [<c01977fc>]  [<c01473e4>]
> [<c01475be>]  [<c0137ac8>]  [<c0137e60>]  [<c0138124>]  [<c0137e60>]
> [<c01381ca>]  [<c014eadb>]  [<c01094cb>]
> [<e09def98>]  [<c01113bf>]  [<c0110ac2>]  [<c014ebce>]  [<c014ee6e>]
> [<c010967f>]
> 

Could you please enable CONFIG_KALLSYMS and regenerate the backtrace?

Thanks.

Re: "bio too big" error

[Jens Axboe]

On Tue, Dec 10 2002, Wil Reichert wrote:
> Exact error with debug is:
> 
> darwin:/a01/mp3s/Skinny Puppy/Too Dark Park# ogg123 -q 01\ -\
> Convulsion.ogg
> bio too big device ide0(3,4) (256 > 255)

looks like a one-off in the dm merge_bvec function.

-- 
Jens Axboe

Re: "bio too big" error

[Wil Reichert]

Could you please enable CONFIG_KALLSYMS and regenerate the backtrace?

darwin:~$ cp /a01/movies/metropolis.avi .
bio too big device ide2(33,0) (256 > 255)
Call Trace:
 [<c02035ee>] generic_make_request+0x1ce/0x210
 [<e093046d>] __clone_and_map+0xbd/0x120 [dm_mod]
 [<e0930558>] __split_bio+0x88/0xb0 [dm_mod]
 [<e09305f5>] dm_request+0x75/0xb0 [dm_mod]
 [<c020359a>] generic_make_request+0x17a/0x210
 [<c01dd314>] radix_tree_extend+0x64/0x90
 [<c0203684>] submit_bio+0x54/0xa0
 [<c017209e>] mpage_bio_submit+0x2e/0x40
 [<c0172689>] mpage_readpages+0xc9/0x160
 [<c0189780>] ext3_get_block+0x0/0xb0
 [<c013a526>] read_pages+0x116/0x120
 [<c0189780>] ext3_get_block+0x0/0xb0
 [<c013853d>] __alloc_pages+0x8d/0x290
 [<c013a624>] do_page_cache_readahead+0xf4/0x180
 [<c013a7fe>] page_cache_readahead+0x14e/0x190
 [<c0135168>] do_generic_mapping_read+0xb8/0x410
 [<c0154443>] __block_commit_write+0x93/0xa0
 [<c0135500>] file_read_actor+0x0/0xf0
 [<c01357c4>] __generic_file_aio_read+0x1d4/0x220
 [<c0135500>] file_read_actor+0x0/0xf0
 [<c013586a>] generic_file_aio_read+0x5a/0x80
 [<c015076b>] do_sync_read+0x8b/0xc0
 [<c0136e3c>] generic_file_write+0x5c/0x80
 [<c015085e>] vfs_read+0xbe/0x130
 [<c0150afe>] sys_read+0x3e/0x60
 [<c01096af>] syscall_call+0x7/0xb

Wil

Re: "bio too big" error

[Wil Reichert]

> Did you try the dm patches that were just posted to lkml today?

Just subscribed today, missed 'em.  You're refering to

http://people.sistina.com/~thornber/patches/2.5-stable/2.5.50/2.5.50-dm-2.tar.bz2 ?

They result in:

darwin:~# /etc/init.d/lvm2 start
Initializing LVM: device-mapper: device /dev/discs/disc4/disc too small
for target
device-mapper: internal error adding target to table
device-mapper: destroying table
  device-mapper ioctl cmd 2 failed: Invalid argument
  Couldn't load device 'cheese_vg-blah'.
  0 logical volume(s) in volume group "cheese_vg" now active
lvm2.

Guess I'll give 2.5.51 w/ the dm patches a shot.

Wil

Re: "bio too big" error

[Greg KH]

On Wed, Dec 11, 2002 at 08:40:35AM -0500, Wil Reichert wrote:
> > Did you try the dm patches that were just posted to lkml today?
> 
> Just subscribed today, missed 'em.  You're refering to
> 
> http://people.sistina.com/~thornber/patches/2.5-stable/2.5.50/2.5.50-dm-2.tar.bz2 ?

Nope, try the ones at:
	http://people.sistina.com/~thornber/patches/2.5-stable/2.5.51/

thanks,

greg k-h

Re: "bio too big" error

[Wil Reichert]

Ok, 2.5.51 plus dm patches result in the following:

Initializing LVM: device-mapper: device
/dev/ide/host2/bus1/target0/lun0/disc too small for target
device-mapper: internal error adding target to table
device-mapper: destroying table
  device-mapper ioctl cmd 2 failed: Invalid argument
  Couldn't load device 'cheese_vg-blah'.
  0 logical volume(s) in volume group "cheese_vg" now active
lvm2.

Was fine (minus of course the entire bio thing) in 50, did something
break in 51 or is it just my box?

Wil

> > > Did you try the dm patches that were just posted to lkml today?
> >
> > Just subscribed today, missed 'em.  You're refering to
> >
> >
>
http://people.sistina.com/~thornber/patches/2.5-stable/2.5.50/2.5.50-dm-2.tar.bz2
?
>
> Nope, try the ones at:
>        
http://people.sistina.com/~thornber/patches/2.5-stable/2.5.51/
> 
> thanks,
>
> greg k-h



__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: "bio too big" error

[Joe Thornber]

On Wed, Dec 11, 2002 at 04:15:42PM -0800, Wil Reichert wrote:
> Ok, 2.5.51 plus dm patches result in the following:
> 
> Initializing LVM: device-mapper: device
> /dev/ide/host2/bus1/target0/lun0/disc too small for target
> device-mapper: internal error adding target to table
> device-mapper: destroying table
>   device-mapper ioctl cmd 2 failed: Invalid argument
>   Couldn't load device 'cheese_vg-blah'.
>   0 logical volume(s) in volume group "cheese_vg" now active
> lvm2.
> 
> Was fine (minus of course the entire bio thing) in 50, did something
> break in 51 or is it just my box?

I've had a couple of reports of this problem.  The offending patch is:

http://people.sistina.com/~thornber/patches/2.5-stable/2.5.51/2.5.51-dm-1/00005.patch

back it out if necc.


All it does is:

--- diff/drivers/md/dm-table.c	2002-12-11 11:59:51.000000000 +0000
+++ source/drivers/md/dm-table.c	2002-12-11 12:00:00.000000000 +0000
@@ -388,7 +388,7 @@
 static int check_device_area(struct dm_dev *dd, sector_t start, sector_t len)
 {
 	sector_t dev_size;
-	dev_size = dd->bdev->bd_inode->i_size;
+	dev_size = dd->bdev->bd_inode->i_size >> SECTOR_SHIFT;
 	return ((start < dev_size) && (len <= (dev_size - start)));
 }


ie. previously we were accidentally comparing bytes with sectors to
verify the device sizes.  So either I'm being very stupid (likely) and
the above patch is bogus, or you really don't have room for this lv.
Can you send me 3 bits of information please:

1) disk/partition sizes for your PVs
2) an LVM2 backup of the metadata (the nice readable ascii one).
3) The version of LVM that *created* the lv.

Thanks,

- Joe

Re: "bio too big" error

[Joe Thornber]

On Wed, Dec 11, 2002 at 08:21:39AM +0100, Jens Axboe wrote:
> On Tue, Dec 10 2002, Wil Reichert wrote:
> > Exact error with debug is:
> > 
> > darwin:/a01/mp3s/Skinny Puppy/Too Dark Park# ogg123 -q 01\ -\
> > Convulsion.ogg
> > bio too big device ide0(3,4) (256 > 255)
> 
> looks like a one-off in the dm merge_bvec function.

Nope, we're not using merge_bvec yet.  Kevin Corry has convinced me
that there is a bug in dms bv splitting code, I'll put out a new
patchset later.  However the known bug wouldn't have a stack trace
like this.

- Joe

Re: "bio too big" error

[Joe Thornber]

On Tue, Dec 10, 2002 at 09:17:45PM -0500, Wil Reichert wrote:
> Hi,
> 
> I'm getting a "bio too big" error with 2.5.50.  I've got a 330G lvm2
> partition formatted with ext3 using the -T largefile4 parameter. 
> Everything seems ok at first, but any sort of access will die very
> unhappily with said error messsage after about 10 seconds of operation
> or so.  The only google search results are the patch submission.  Eeek.

Could you try the patchset below please ?  (you may need to knock out
patch 5 until we get to the bottom of that particular bug).

http://people.sistina.com/~thornber/patches/2.5-stable/2.5.51/2.5.51-dm-2.tar.bz2

- Joe

Re: "bio too big" error

[Wil Reichert]

> ie. previously we were accidentally comparing bytes with sectors to
> verify the device sizes.  So either I'm being very stupid (likely) and
> the above patch is bogus, or you really don't have room for this lv.
> Can you send me 3 bits of information please:
Well, it works fine w/ the 2.4 kernel & prior 2.5's, I think my lv is
fine...

> 1) disk/partition sizes for your PVs
spans 4 entire discs and one partition
Disk /dev/discs/disc4/disc: 80.0 GB, 80039116800 bytes
Disk /dev/discs/disc1/disc: 123.5 GB, 123522416640 bytes
Disk /dev/ide/host2/bus1/target0/lun0/disc: 100.0 GB, 100030242816 bytes
Disk /dev/ide/host2/bus0/target1/lun0/disc: 10.1 GB, 10110320640 bytes
/dev/discs/disc0/part4         40072    119150  39855816   8e  Linux LVM

Dunno if it matters, but the 80G is 2 striped 40s on a 3ware controller,
the 120, 100, and 10 are on a Promise U133 card, and the 40 gig
partition is on the native VIA controller.  Top it all of this is an SMP
box.

> 2) an LVM2 backup of the metadata (the nice readable ascii one).
/etc/lvm/backup/cheese_vg -

# Generated by LVM2: Tue Dec 10 21:11:37 2002

contents = "Text Format Volume Group"
version = 1

description = "Created *after* executing 'vgconvert -M2 cheese_vg'"

creation_host = "darwin"        # Linux darwin 2.4.19 #1 SMP Wed Nov 13
16:54:28 EST 2002 i686
creation_time = 1039572697      # Tue Dec 10 21:11:37 2002

cheese_vg {
        id = "WF3vAx-k1r3-NUjU-az7z-I4SM-oorx-rvoYSt"
        seqno = 1
        status = ["RESIZEABLE", "READ", "WRITE"]
        system_id = "darwin1025684717"
        extent_size = 32768             # 16 Megabytes
        max_lv = 256
        max_pv = 256

        physical_volumes {

                pv0 {
                        id = "XFexK7-KqnW-dt7I-JHfB-gC8t-8Z45-RLiCEW"
                        device = "/dev/discs/disc4/disc"        # Hint
only
                        status = ["ALLOCATABLE"]
                        pe_start = 33152
                        pe_count = 4769 # 74.5156 Gigabytes
                }

                pv1 {
                        id = "7swUJv-wGiq-9uCz-xiKK-owvf-p77g-zGU1C5"
                        device = "/dev/discs/disc1/disc"        # Hint
only

                        status = ["ALLOCATABLE"]
                        pe_start = 33152
                        pe_count = 7361 # 115.016 Gigabytes
                }

                pv2 {
                        id = "z1Zxq5-X1JX-q08r-epqS-T0V7-003q-admD5T"
                        device =
"/dev/ide/host2/bus1/target0/lun0/disc"# Hint only

                        status = ["ALLOCATABLE"]
                        pe_start = 33152
                        pe_count = 5961 # 93.1406 Gigabytes
                }

                pv3 {
                        id = "zfuSRQ-mYYI-pGHR-9Mu2-uFWu-JQiH-JZyO7I"
                        device = "/dev/discs/disc0/part4"       # Hint
only

                        status = ["ALLOCATABLE"]
                        pe_start = 33152
                        pe_count = 2431 # 37.9844 Gigabytes
                }

                pv4 {
                        id = "TNYATl-VrjS-Dt4T-e906-Ilb3-bgu7-JQS1sb"
                        device =
"/dev/ide/host2/bus0/target1/lun0/disc"# Hint only

                        status = ["ALLOCATABLE"]
                        pe_start = 33152
                        pe_count = 601  # 9.39062 Gigabytes
                }
        }

        logical_volumes {

                blah {
                        id = "000000-0000-0000-0000-0000-0000-000000"
                        status = ["READ", "WRITE", "VISIBLE"]
                        allocation_policy = "next free"
                        read_ahead = 1024
                        segment_count = 7

                        segment1 {
                                start_extent = 0
                                extent_count = 4769     # 74.5156
Gigabytes

                                type = "striped"
                                stripe_count = 1        # linear

                                stripes = [
                                        "pv0", 0
                                ]
                        }
                        segment2 {
                                start_extent = 4769
                                extent_count = 1409     # 22.0156
Gigabytes

                                type = "striped"
                                stripe_count = 1        # linear

                                stripes = [
                                        "pv2", 4552
                                ]
                        }
                        segment3 {
                                start_extent = 6178
                                extent_count = 2255     # 35.2344
Gigabytes

                                type = "striped"
                                stripe_count = 1        # linear

                                stripes = [
                                        "pv3", 0
                                ]
                        }
                        segment4 {
                                start_extent = 8433
                                extent_count = 7361     # 115.016
Gigabytes

                                type = "striped"
                                stripe_count = 1        # linear

                                stripes = [
                                        "pv1", 0
                                ]
                        }
                        segment5 {
                                start_extent = 15794
                                extent_count = 4552     # 71.125
Gigabytes

                                type = "striped"
                                stripe_count = 1        # linear

                                stripes = [
                                        "pv2", 0
                                ]
                        }
                        segment6 {
                                start_extent = 20346
                                extent_count = 176      # 2.75 Gigabytes

                                type = "striped"
                                stripe_count = 1        # linear

                                stripes = [
                                        "pv3", 2255
                                ]
                        }
                        segment7 {
                                start_extent = 20522
                                extent_count = 601      # 9.39062
Gigabytes

                                type = "striped"
                                stripe_count = 1        # linear

                                stripes = [
                                        "pv4", 0
                                ]
                        }
                }
        }
}


> 3) The version of LVM that *created* the lv.
1.0.3, I **think**.  I know it rev'd to 1.0.4 or 1.0.5 before I added
another disc or two.  Upgraded to lvm2 a couple  months back.  Just
recently did a 'vgconvert -M2 cheese_vg' to see if that helped things,
but didn't seem to matter.

Wil

Re: "bio too big" error

[Wil Reichert]

Yeah, ditching patch 5 makes my lvm functional again.  Things are
definately better now.  I haven't attempted to stress it, but the entire
hanging console / zombie process bit has gone away.  Everything appears
to work normally.  A couple test cp's shows nothing abnormal, but
playing an ogg still results in the following.

Dec 12 13:32:20 darwin kernel: bio too big device ide2(33,0) (256 > 255)
Dec 12 13:32:51 darwin last message repeated 3 times
Dec 12 13:33:55 darwin last message repeated 6 times

Any other tests I should do?

Wil

On Thu, 2002-12-12 at 07:08, Joe Thornber wrote:
> On Tue, Dec 10, 2002 at 09:17:45PM -0500, Wil Reichert wrote:
> > Hi,
> > 
> > I'm getting a "bio too big" error with 2.5.50.  I've got a 330G lvm2
> > partition formatted with ext3 using the -T largefile4 parameter. 
> > Everything seems ok at first, but any sort of access will die very
> > unhappily with said error messsage after about 10 seconds of operation
> > or so.  The only google search results are the patch submission.  Eeek.
> 
> Could you try the patchset below please ?  (you may need to knock out
> patch 5 until we get to the bottom of that particular bug).
> 
> http://people.sistina.com/~thornber/patches/2.5-stable/2.5.51/2.5.51-dm-2.tar.bz2
> 
> - Joe
-- 
Wil Reichert <wilreichert@yahoo.com>

Re: "bio too big" error

[Joe Thornber]

On Thu, Dec 12, 2002 at 01:34:59PM -0500, Wil Reichert wrote:
> Yeah, ditching patch 5 makes my lvm functional again.  Things are
> definately better now.  I haven't attempted to stress it, but the entire
> hanging console / zombie process bit has gone away.  Everything appears
> to work normally.  A couple test cp's shows nothing abnormal, but
> playing an ogg still results in the following.
> 
> Dec 12 13:32:20 darwin kernel: bio too big device ide2(33,0) (256 > 255)
> Dec 12 13:32:51 darwin last message repeated 3 times
> Dec 12 13:33:55 darwin last message repeated 6 times
> 
> Any other tests I should do?

I'm now seeing some corruption with large files, so I'll fix that and
hope that it solves your problem too.  wrt. the device size bug that
you're experiencing could you mail me (not the list) your .config
please ?

- Joe

Re: "bio too big" error

[Kevin Corry]

On Thursday 12 December 2002 03:12, Joe Thornber wrote:
> On Wed, Dec 11, 2002 at 04:15:42PM -0800, Wil Reichert wrote:
> > Ok, 2.5.51 plus dm patches result in the following:
> >
> > Initializing LVM: device-mapper: device
> > /dev/ide/host2/bus1/target0/lun0/disc too small for target
> > device-mapper: internal error adding target to table
> > device-mapper: destroying table
> >   device-mapper ioctl cmd 2 failed: Invalid argument
> >   Couldn't load device 'cheese_vg-blah'.
> >   0 logical volume(s) in volume group "cheese_vg" now active
> > lvm2.
> >
> > Was fine (minus of course the entire bio thing) in 50, did something
> > break in 51 or is it just my box?
>
> I've had a couple of reports of this problem.  The offending patch is:
>
> http://people.sistina.com/~thornber/patches/2.5-stable/2.5.51/2.5.51-dm-1/0
>0005.patch
>
> back it out if necc.
>
> All it does is:
>
> --- diff/drivers/md/dm-table.c	2002-12-11 11:59:51.000000000 +0000
> +++ source/drivers/md/dm-table.c	2002-12-11 12:00:00.000000000 +0000
> @@ -388,7 +388,7 @@
>  static int check_device_area(struct dm_dev *dd, sector_t start, sector_t
> len) {
>  	sector_t dev_size;
> -	dev_size = dd->bdev->bd_inode->i_size;
> +	dev_size = dd->bdev->bd_inode->i_size >> SECTOR_SHIFT;
>  	return ((start < dev_size) && (len <= (dev_size - start)));
>  }


Actually, this 00005.patch *is* necessary. dd->bdev->bd_inode->i_size *is* in 
bytes, and does need to be shifted to do the above comparison.

I believe we have tracked the problem down to the call to dm_get_device() in 
dm-linear.c. It is passing in an incorrect value, which winds up being the 
"start" parameter to the check_device_area() function. I've included a patch 
at the end of this email which I believe should fix the problem. I have also 
checked dm-stripe.c, and it appears to make the call to dm_get_device() 
correctly, so no worries there.

-- 
Kevin Corry
corryk@us.ibm.com
http://evms.sourceforge.net/



--- linux-2.5.51a/drivers/md/dm-linear.c	2002/11/20 20:09:22	1.1
+++ linux-2.5.51b/drivers/md/dm-linear.c	2002/12/12 21:38:32
@@ -43,7 +43,7 @@
 		goto bad;
 	}
 
-	if (dm_get_device(ti, argv[0], ti->begin, ti->len,
+	if (dm_get_device(ti, argv[0], lc->start, ti->len,
 			  dm_table_get_mode(ti->table), &lc->dev)) {
 		ti->error = "dm-linear: Device lookup failed";
 		goto bad;