Re: new Areca driver in 2.6.16-rc6-mm2 appears to be broken

["erich" <erich@areca.com.tw>]

Dear Jens Axboe,

I had found a big difference of generic_make_request(struct bio *bio)
got message : sdb1: rw=0, want=...., limit=.....


*****************
** TEST 1
*****************

I used "MAX_XFER_SECTORS  4096" driver to do mkfs.ext2 with ARECA RAID 
volume sdb1.
and copy a big file (900MB) into sdb1.
If I copy this file from sdb1, the message rw=.... ,want=......, 
limit=...... will appear immediately.

When I reboot the system and used  "MAX_XFER_SECTORS  512" driver.
I copy this big file from sdb1, the message rw=.... ,want=......, 
limit=...... still appear immediately.

When I redo mkfs.ext2 with ARECA RAID volume sdb1 (used  "MAX_XFER_SECTORS 
512")
and copy the same file (900MB) into sdb1.
I copy this file from sdb1 again,the message rw=.... ,want=......, 
limit=...... disappear.

****************
** TEST 2
****************

When I do another test with "MAX_XFER_SECTORS  4096" driver

#echo 0 > /sys/block/sdb/queue/read_ahead_kb
#mkfs.ext2 /dev/sdb1

then copy the same file (900MB) into sdb1.
I copy this file from sdb1 again,the message rw=.... ,want=......, 
limit=...... disappear.
Even I redo "echo 4096 > /sys/block/sdb/queue/read_ahead_kb" with ARECA RAID 
volume.
The message rw=.... ,want=......, limit=...... never appear at my "copy 
compare" test script.

Now I can say the bug come from "block read ahead".

And this bug will certainly appear when do "mkfs.ext2" if read_ahead_kb 
value large enough.


Best Regards
Erich Chen
----- Original Message ----- 
From: "Jens Axboe" <axboe@suse.de>
To: "Andrew Morton" <akpm@osdl.org>
Cc: "James Bottomley" <James.Bottomley@steeleye.com>; <erich@areca.com.tw>
Sent: Friday, March 31, 2006 3:42 PM
Subject: Re: new Areca driver in 2.6.16-rc6-mm2 appears to be broken


> (irk, Erich wasn't in the cc, sorry to Andrew and James for getting this
> mail twice)
>
> On Thu, Mar 30 2006, Andrew Morton wrote:
> > "erich" <erich@areca.com.tw> wrote:
> > >
> > > Dear Chris Caputo,
> > >
> > >  Thanks you to conform this issue again, my colleague assisted me and 
> > > to
> > >  double check my older version driver yesterday.
> > >  and the old driver is working fine as your mention before.
> > >
> > >  The ARCMSR_MAX_XFER_SECTORS is the reason why cause "attempt to access
> > >  beyond end of device".
> > >
> > >  #define ARCMSR_MAX_XFER_SECTORS
> > >  256     -----old
> > >  #define ARCMSR_MAX_XFER_SECTORS
> > >  4096     -----new
> >
> > That seems odd.  ARCMSR_MAX_XFER_SECTORS just gets put into
> > scsi_host_template.max_sectors.  Could it be a scsi core buglet?
>
> Perhaps the larger max sectors setting is causing read-ahead to be
> overly optimistic and going beyond the end? Should not happen.
>
> Erich, can you try and shrink read-ahead on that device and retest?
> Basically just do
>
> # echo 0 > /sys/block/sdX/queue/read_ahead_kb
>
> and see if it still complains.
>
> --
> Jens Axboe

-
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/