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;
Attachment:
test.img.bz2
Description: application/bzip
