From patchwork Mon Jul 8 21:27:21 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Sandeen X-Patchwork-Id: 257608 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 96DAD2C0089 for ; Tue, 9 Jul 2013 07:27:23 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753156Ab3GHV1W (ORCPT ); Mon, 8 Jul 2013 17:27:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:65139 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753087Ab3GHV1W (ORCPT ); Mon, 8 Jul 2013 17:27:22 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r68LRM4W002003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 8 Jul 2013 17:27:22 -0400 Received: from Liberator-563.local (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r68LRL0F030105 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 8 Jul 2013 17:27:21 -0400 Message-ID: <51DB2EB9.4010903@redhat.com> Date: Mon, 08 Jul 2013 16:27:21 -0500 From: Eric Sandeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ext4 development Subject: Re: [PATCH] e2fsprogs: allocate inode table wholly within group References: <51D3269B.5080608@redhat.com> In-Reply-To: <51D3269B.5080608@redhat.com> X-Enigmail-Version: 1.5.1 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Ok, resetting a little on this one. The actual problem seems to be that the test does successive "-M" minimal resizes, and eventually we resize into the middle of an inode table, leaving the end of the table beyond the fs. Point "resize2fs -M" at the attached image once or twice w/ fscks in between and you should see it. It seems like the obvious fix would be to move the inode table if necessary, as with the following patch. But then of course we find that we've run out of room to move the table, and the resize fails; so we've let resize2fs choose its own minimum size - which which it cannot handle. Presumably something's gone wrong in calculate_minimum_resize_size(), though I can't tell what. Truth be told, I'm not enjoying resize2fs right now! diff --git a/resize/resize2fs.c b/resize/resize2fs.c index 204b10a..27dc5e6 100644 --- a/resize/resize2fs.c +++ b/resize/resize2fs.c @@ -891,18 +891,25 @@ static errcode_t blocks_to_move(ext2_resize_t rfs) new_size = ext2fs_blocks_count(fs->super); if (new_size < ext2fs_blocks_count(old_fs->super)) { for (g = 0; g < fs->group_desc_count; g++) { + int realloc = 0; /* * ext2fs_allocate_group_table re-allocates bitmaps * which are set to block 0. */ if (ext2fs_block_bitmap_loc(fs, g) >= new_size) { ext2fs_block_bitmap_loc_set(fs, g, 0); - retval = ext2fs_allocate_group_table(fs, g, 0); - if (retval) - return retval; + realloc = 1; } if (ext2fs_inode_bitmap_loc(fs, g) >= new_size) { ext2fs_inode_bitmap_loc_set(fs, g, 0); + realloc = 1; + } + if (ext2fs_inode_table_loc(fs, g) + fs->inode_blocks_per_group > new_size) { + ext2fs_inode_table_loc_set(fs, g, 0); + realloc = 1; + } + + if (realloc) { retval = ext2fs_allocate_group_table(fs, g, 0); if (retval) return retval;