Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756172AbYH2XQA (ORCPT ); Fri, 29 Aug 2008 19:16:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754152AbYH2XNb (ORCPT ); Fri, 29 Aug 2008 19:13:31 -0400 Received: from g1t0027.austin.hp.com ([15.216.28.34]:5640 "EHLO g1t0027.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751828AbYH2XN2 (ORCPT ); Fri, 29 Aug 2008 19:13:28 -0400 From: Andrew Patterson Subject: [PATCH 6/6] Call flush_disk() after detecting an online resize. To: linux-scsi@vger.kernel.org Cc: andrew.patterson@hp.com, James.Bottomley@HansenPartnership.com, linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, axboe@kernel.dk, andmike@linux.vnet.ibm.com, mike.miller@hp.com, genanr@emsphone.com, jmoyer@redhat.com Date: Fri, 29 Aug 2008 17:13:26 -0600 Message-ID: <20080829231325.25065.48172.stgit@bluto.andrew> In-Reply-To: <20080829231254.25065.66052.stgit@bluto.andrew> References: <20080829231254.25065.66052.stgit@bluto.andrew> User-Agent: StGIT/0.14.2 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2553 Lines: 63 Call flush_disk() after detecting an online resize. We call flush_disk() to make sure the buffer cache for the disk is flushed after a disk resize. There are two resize cases, growing and shrinking. Given that users can shrink/then grow a disk before revalidate_disk() is called, we treat the grow case identically to shrinking. We need to flush the buffer cache after an online shrink because, as James Bottomley puts it, The two use cases for shrinking I can see are 1. planned: the fs is already shrunk to within the new boundaries and all data is relocated, so invalidate is fine (any dirty buffers that might exist in the shrunk region are there only because they were relocated but not yet written to their original location). 2. unplanned: In this case, the fs is probably toast, so whether we invalidate or not isn't going to make a whole lot of difference; it's still going to try to read or write from sectors beyond the new size and get I/O errors. Immediately invalidating shrunk disks will cause errors for outstanding I/Os for reads/write beyond the new end of the disk to be generated earlier then if we waited for the normal buffer cache operation. It also removes a potential security hole where we might keep old data around from beyond the end of the shrunk disk if the disk was not invalidated. Signed-off-by: Andrew Patterson --- fs/block_dev.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/block_dev.c b/fs/block_dev.c index 5ce28b1..6cb00dd 100644 --- a/fs/block_dev.c +++ b/fs/block_dev.c @@ -885,8 +885,8 @@ static void flush_disk(struct block_device *bdev) if (bdev->bd_disk) disk_name(bdev->bd_disk, 0, name); - printk(KERN_WARNING "VFS: busy inodes on changed media %s\n", - name); + printk(KERN_WARNING "VFS: busy inodes on changed media or " + "resized disk %s\n", name); } if (!bdev->bd_disk) @@ -919,6 +919,7 @@ void check_disk_size_change(struct gendisk *disk, struct block_device *bdev) "%s: detected capacity change from %lld to %lld\n", name, bdev_size, disk_size); i_size_write(bdev->bd_inode, disk_size); + flush_disk(bdev); } } EXPORT_SYMBOL(check_disk_size_change); -- 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/