From patchwork Fri Jun 21 02:47:07 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Theodore Ts'o X-Patchwork-Id: 253123 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 4AB8B2C029E for ; Fri, 21 Jun 2013 12:47:14 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423038Ab3FUCrN (ORCPT ); Thu, 20 Jun 2013 22:47:13 -0400 Received: from li9-11.members.linode.com ([67.18.176.11]:59965 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965231Ab3FUCrM (ORCPT ); Thu, 20 Jun 2013 22:47:12 -0400 Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.80) (envelope-from ) id 1UprSF-00018b-4e; Fri, 21 Jun 2013 02:52:03 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id E99865804AF; Thu, 20 Jun 2013 22:47:07 -0400 (EDT) Date: Thu, 20 Jun 2013 22:47:07 -0400 From: Theodore Ts'o To: Eric Sandeen Cc: ext4 development , Leonardo Menezes Vaz Subject: Re: [PATCH] resize2fs: move bitmaps if shrinking would orphan them Message-ID: <20130621024707.GC10730@thunk.org> References: <51C0FA44.3030600@redhat.com> <51C10B41.9020103@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <51C10B41.9020103@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue, Jun 18, 2013 at 08:37:05PM -0500, Eric Sandeen wrote: > It is possible to have a flex_bg filesystem with block groups > which have inode & block bitmaps at some point well past the > start of the group. > > If an offline shrink puts the new size somewhere between > the start of the block group and the (old) location of > the bitmaps, they can be left beyond the end of the filesystem, > i.e. result in fs corruption. > > Check each remaining block group for whether its bitmaps > are beyond the end of the new filesystem, and reallocate > them in a new location if needed. > > Signed-off-by: Eric Sandeen Looks good, thanks for the patch. I made a few minor changes to fix up some extra whitespace and a minor optimization. - Ted --- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/resize/resize2fs.c b/resize/resize2fs.c index 28131c2..204b10a 100644 --- a/resize/resize2fs.c +++ b/resize/resize2fs.c @@ -889,7 +889,7 @@ static errcode_t blocks_to_move(ext2_resize_t rfs) * bitmaps which are beyond the end of the new filesystem. */ new_size = ext2fs_blocks_count(fs->super); - if (ext2fs_blocks_count(fs->super) < ext2fs_blocks_count(old_fs->super)) { + if (new_size < ext2fs_blocks_count(old_fs->super)) { for (g = 0; g < fs->group_desc_count; g++) { /* * ext2fs_allocate_group_table re-allocates bitmaps @@ -900,13 +900,13 @@ static errcode_t blocks_to_move(ext2_resize_t rfs) retval = ext2fs_allocate_group_table(fs, g, 0); if (retval) return retval; - } + } if (ext2fs_inode_bitmap_loc(fs, g) >= new_size) { ext2fs_inode_bitmap_loc_set(fs, g, 0); retval = ext2fs_allocate_group_table(fs, g, 0); if (retval) return retval; - } + } } }