From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755926AbZFCVnk (ORCPT ); Wed, 3 Jun 2009 17:43:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754276AbZFCVnd (ORCPT ); Wed, 3 Jun 2009 17:43:33 -0400 Received: from mga01.intel.com ([192.55.52.88]:11776 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754007AbZFCVnc (ORCPT ); Wed, 3 Jun 2009 17:43:32 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.41,300,1241420400"; d="scan'208";a="463191108" From: "Luck, Tony" To: Robert Hancock Cc: linux-kernel@vger.kernel.org, Jeff Moyer Subject: Re: linux-next end of partition problems? In-Reply-To: <4A25F5F7.9020506@gmail.com> References: <4a25b8e987329b28c@agluck-desktop.sc.intel.com> <4A25F5F7.9020506@gmail.com> Date: Wed, 03 Jun 2009 14:43:34 -0700 Message-Id: <4a26ee864930956be@agluck-desktop.sc.intel.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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 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 Signed-off-by: Jens Axboe 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