Re: linux-next end of partition problems?

[Luck, Tony]

> What kind of controller/drive is this?

lspci says the controller is:
06:02.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 07)

console log says drive is:
scsi 0:0:1:0: Direct-Access     SEAGATE  ST318406LC       010A PQ: 0 ANSI: 3
 target0:0:1: Beginning Domain Validation
 target0:0:1: Ending Domain Validation
 target0:0:1: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 63)
sd 0:0:1:0: [sdb] 35843670 512-byte hardware sectors: (18.3 GB/17.0 GiB)
sd 0:0:1:0: [sdb] Write Protect is off
sd 0:0:1:0: [sdb] Mode Sense: 9f 00 10 08
scsi 0:0:6:0: Processor         ESG-SHV  SCA HSBP M17     1.0D PQ: 0 ANSI: 2
 target0:0:6: Beginning Domain Validation
sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
 target0:0:6: Ending Domain Validation
 target0:0:6: asynchronous
 sdb: sdb1 sdb2 sdb3
sd 0:0:1:0: [sdb] Attached SCSI disk

A git bisect between v2.6.30-rc7(good) and next-20090602(bad) points
the finger at this commit (and reverting this change from next-20090602
confirms it introduces this problem):


commit db2dbb12dc47a50c7a4c5678f526014063e486f6
Author: Jeff Moyer <jmoyer@xxxxxxxxxx>
Date:   Wed Apr 22 14:08:13 2009 +0200

    block: implement blkdev_readpages
    
    Doing a proper block dev ->readpages() speeds up the crazy dump(8)
    approach of using interleaved process IO.
    
    Signed-off-by: Jeff Moyer <jmoyer@xxxxxxxxxx>
    Signed-off-by: Jens Axboe <jens.axboe@xxxxxxxxxx>

diff --git a/fs/block_dev.c b/fs/block_dev.c
index f45dbc1..a85fe31 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -331,6 +331,12 @@ static int blkdev_readpage(struct file * file, struct page * page)
 	return block_read_full_page(page, blkdev_get_block);
 }
 
+static int blkdev_readpages(struct file *file, struct address_space *mapping,
+			struct list_head *pages, unsigned nr_pages)
+{
+	return mpage_readpages(mapping, pages, nr_pages, blkdev_get_block);
+}
+
 static int blkdev_write_begin(struct file *file, struct address_space *mapping,
 			loff_t pos, unsigned len, unsigned flags,
 			struct page **pagep, void **fsdata)
@@ -1399,6 +1405,7 @@ static int blkdev_releasepage(struct page *page, gfp_t wait)
 
 static const struct address_space_operations def_blk_aops = {
 	.readpage	= blkdev_readpage,
+	.readpages	= blkdev_readpages,
 	.writepage	= blkdev_writepage,
 	.sync_page	= block_sync_page,
 	.write_begin	= blkdev_write_begin,


On a random hunch, I wondered whether this error message was connected to
the fact that ia64 kernel has a 64K page size.  I re-built using a 4k
pagesize ... and this also make the partition overrun message go away.

So is it plausible that the blkdev_readpages() code is resulting in some
readahead of a page that overlaps the partition end?  The partition size
(15832057 * 1K block according to /proc/partitions) is not a multiple of
the 64K page size ... but then it isn't a multiple of 4K either :-(

-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/