fix up lazy_bg bitmap initialization at mkfs time

While trying out the -O lazy_bg option, I ran into some trouble on my big filesystem. The journal size was > free blocks in the first block group, so it spilled into the next bg with available blocks. Since we are using lazy_bg here, that -should- have been the last block group. But, when setup_lazy_bg() marks block groups as UNINIT, it doesn't do anything with the bitmaps (as designed). However, the block allocation routine simply searches the bitmap for next available blocks, and finds them in the 2nd bg, despite it being marked UNINIT - the summaries aren't checked during allocation. This also caused the 1st group free block numbers to get out of whack, as we start subtracting from zero:

Group 0: block bitmap at 1025, inode bitmap at 1026, inode table at 1027
0 free blocks, 16373 free inodes, 2 used directories
Group 1: block bitmap at 33793, inode bitmap at 33794, inode table at 33795
63957 free blocks, 0 free inodes, 0 used directories [Inode not init, Block not init]
Group 2: block bitmap at 65536, inode bitmap at 65537, inode table at 65538
0 free blocks, 0 free inodes, 0 used directories [Inode not init, Block not init]

The following patch seems to fix this up for me; just mark the in-memory bitmaps as full for any bg's we flag as UNINIT. The bitmaps aren't marked as dirty, so they won't be written out. When bitmaps are re-read on the next invocation of debugfs, etc, the UNINIT flag will be found, and again the in-memory bitmaps will be marked as full.

This has the somewhat interesting, but correct, result of making the journal blocks land in both the first and last bgs of a 16T filesystem: :)

BLOCKS:
(0-11):1520-1531, (IND):1532, (12-1035):1533-2556, <...> (IND):4194272286, (31756-32768):4194272287-419427329

Unfortunately it also increases mkfs time a bit, as it must search a huge string of unavailable blocks if it has to allocate in the last bg. Ah well...

Thanks,
-Eric

Index: e2fsprogs-1.39_ext4_hg/misc/mke2fs.c
===================================================================
@@ -450,16 +450,22 @@ static void setup_lazy_bg(ext2_filsys fs
 	int blks;
 	struct ext2_super_block *sb = fs->super;
 	struct ext2_group_desc *bg = fs->group_desc;
+	char *block_bitmap = fs->block_map->bitmap;
+	char *inode_bitmap = fs->inode_map->bitmap;
+	int block_nbytes = (int) EXT2_BLOCKS_PER_GROUP(fs->super) / 8;
+	int inode_nbytes = (int) EXT2_INODES_PER_GROUP(fs->super) / 8;
 
 	if (EXT2_HAS_COMPAT_FEATURE(fs->super, 
 				    EXT2_FEATURE_COMPAT_LAZY_BG)) {
 		for (i = 0; i < fs->group_desc_count; i++, bg++) {
 			if ((i == 0) ||
 			    (i == fs->group_desc_count-1))
-				continue;
+				goto skip;
 			if (bg->bg_free_inodes_count ==
 			    sb->s_inodes_per_group) {
 				bg->bg_free_inodes_count = 0;
+				/* NB: set in mem only, see also read_bitmaps */
+				memset(inode_bitmap, 0xff, inode_nbytes);
 				bg->bg_flags |= EXT2_BG_INODE_UNINIT;
 				sb->s_free_inodes_count -= 
 					sb->s_inodes_per_group;

@@ -467,9 +473,13 @@ static void setup_lazy_bg(ext2_filsys fs
 			blks = ext2fs_super_and_bgd_loc(fs, i, 0, 0, 0, 0);
 			if (bg->bg_free_blocks_count == blks) {
 				bg->bg_free_blocks_count = 0;
+				memset(block_bitmap, 0xff, block_nbytes);
 				bg->bg_flags |= EXT2_BG_BLOCK_UNINIT;
 				sb->s_free_blocks_count -= blks;
 			}
+skip:
+			block_bitmap += block_nbytes;
+			inode_bitmap += inode_nbytes;
 		}
 	}
 }

Just as an FYI - it probably makes little sense to have a 128MB journal for a filesystem you want to use for testing, since it would still write 128MB to your loopback device when zeroing the journal. It still makes sense for mke2fs and libext2fs to be fixed for correctness, but I think it also makes sense for lazy_bg to influence the journal size.

It also probably makes sense for libext2fs to check group descriptors while allocating...

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

yup, it probably should change that heuristic. With lazy_bg, it should probably look at something like blocks per group * 2 instead of total filesystem blocks... see below.

yeah... I was going with the "lazy" theme. ;-) (and the small-functional-change-at-a-time theme...) But for large filesystems, that would certainly be a bonus.

/*
* Stupid algorithm --- we now just search forward starting from the
* goal. Should put in a smarter one someday....
*/
errcode_t ext2fs_new_block(...

I get the impression that allocation in libext2 is not too glorious in the first place... :)

-Eric

Anyway, how about something like this for calculating journal size in the face of lazy_bg. I know the last group may be smaller... but I figure this is just a heuristic anyway.

Index: e2fsprogs-1.39_ext4_hg/misc/util.c
===================================================================
@@ -252,8 +252,16 @@ void parse_journal_opts(const char *opts
 int figure_journal_size(int size, ext2_filsys fs)
 {
 	blk_t j_blocks;
+	blk_t fs_size;
 
-	if (fs->super->s_blocks_count < 2048) {
+	if (EXT2_HAS_COMPAT_FEATURE(fs->super, 
+ 				    EXT2_FEATURE_COMPAT_LAZY_BG)) {
+		fs_size = fs->super->s_blocks_per_group * 2; 
+	} else {
+		fs_size = fs->super->s_blocks_count;
+	}
+
+	if (fs_size < 2048) {
 		fputs(_("\nFilesystem too small for a journal\n"), stderr);
 		return 0;
 	}

@@ -276,13 +284,13 @@ int figure_journal_size(int size, ext2_f
 		return j_blocks;
 	}
 
-	if (fs->super->s_blocks_count < 32768)
+	if (fs_size < 32768)
 		j_blocks = 1400;
-	else if (fs->super->s_blocks_count < 256*1024)
+	else if (fs_size < 256*1024)
 		j_blocks = 4096;
-	else if (fs->super->s_blocks_count < 512*1024)
+	else if (fs_size < 512*1024)
 		j_blocks = 8192;
-	else if (fs->super->s_blocks_count < 1024*1024)
+	else if (fs_size < 1024*1024)
 		j_blocks = 16384;
 	else
 		j_blocks = 32768;