Place the allocation bitmaps and inode table blocks so they are
adjacent, even in the last flexbg.
Previously, after running "mke2fs -t ext4 DEV 286720", the layout of
the last few block groups would look like this:
Group 32: (Blocks 262145-270336) [INODE_UNINIT, ITABLE_ZEROED]
Block bitmap at 262145 (+0), Inode bitmap at 262161 (+16)
Inode table at 262177-262432 (+32)
Group 33: (Blocks 270337-278528) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
Block bitmap at 262146 (bg #32 + 1), Inode bitmap at 262162 (bg #32 + 17)
Inode table at 262433-262688 (bg #32 + 288)
Group 34: (Blocks 278529-286719) [INODE_UNINIT, ITABLE_ZEROED]
Block bitmap at 262147 (bg #32 + 2), Inode bitmap at 262163 (bg #32 + 18)
Inode table at 262689-262944 (bg #32 + 544)
Now, they look like this:
Group 32: (Blocks 262145-270336) [INODE_UNINIT, ITABLE_ZEROED]
Block bitmap at 262145 (+0), Inode bitmap at 262148 (+3)
Inode table at 262151-262406 (+6)
Group 33: (Blocks 270337-278528) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
Block bitmap at 262146 (bg #32 + 1), Inode bitmap at 262149 (bg #32 + 4)
Inode table at 262407-262662 (bg #32 + 262)
Group 34: (Blocks 278529-286719) [INODE_UNINIT, ITABLE_ZEROED]
Block bitmap at 262147 (bg #32 + 2), Inode bitmap at 262150 (bg #32 + 5)
Inode table at 262663-262918 (bg #32 + 518)
This reduces the free space fragmentation in a freshly created file
system. It also allows the following mke2fs command to succeed:
mke2fs -t ext4 -b 4096 -O ^resize_inode -G $((2**20)) DEV 2130483
(Note that while this allows people to run mke2fs with insanely large
flexbg sizes, this is not a recommended practice, as the kernel may
refuse to resize such a file system while mounted, since it currently
tries to allocate an in-memory data structure based on the size of the
flexbg, and so a file system with a very large flexbg size will cause
the memory allocation to fail. This will hopefully be fixed in a
future kernel release, but if the goal is to force all of the metadata
blocks to be at the beginning of the file system, it's better to use
the packed_meta_blocks configuration parameter in mke2fs.conf.)
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
These images contain various forms of corrupted filesystem which
e2fsck will correct. They are used as a regression test for e2fsck.
The test_script program will automatically run e2fsck against the
filesystem images. It will run them two times, and display the exit
status for each run. The meaning of the exit status codes are as
follows:
0 No filesystem errors were detected
1 Filesystem errors detected, but corrected
2 System should be rebooted
4 Filesystem errors left uncorrected
8 Operational error (generally means internal error,
or filesystem error that the e2fsck was not
prepared to deal with)
16 Usage or syntax error
During the regression test, the first exit code should be 1, and the
second exit code should be 0. In other words, all (with one
exception) of the test filesystems in this directory have some sort of
filesystem corruption, which e2fsck should fix on the first pass.
After the first pass, e2fsck should leave a fully consistent
filesystem with no detectable errors found in the second pass. The
exception is the okgroup.img filesystem, which contains no errors, and
so both exit codes should be 0.
NOTE: It appears that at least some versions of the original e2fsck do
not exit with an exit status code of 1 after correcting filesystem
errors. So if you modify the test_script to try running these
filesystems against the original e2fsck, you will have to inspect the
test_script.log file manually.
--------------------------------------------------------------
Here's a one-line descriptons of the various test images in this
directory:
baddir.img Filesystem with a corrupted directory
badbblocks.img Filesystem with illegal blocks in the bad block inode.
badinode.img Filesystem with various different corrupted inode
entries.
badlkcnt.img Filesystem with deleted files with non-zero link count
badroot.img Filesystem with a file for a root directory
badtable.img Filesystem with blocks shared between the bitmaps and
inode table blocks and the bad block inode
bbfile.img Filesystem with files containing bad blocks
bitmaps.img Filesystem with corrupted inode and block bitmaps
dirlink.img Filesystem with a hard link to a directory
dup.img Filesystem with blocks claimed by two different files
dup2.img Filesystem with blocks claimed by three different files
dupfsblks.img Filesystem with blocks claimed by a file and
inode/block bitmaps and inode tables
dupsuper.img Filesystem with blocks claimed by a file and
the superblock / group descriptors
end-bitmap.img Filesystem with corruption at the end of the block
bitmap
expand.img Tests e2fsck's ability to expand lost+found if
necessary
lpf.img Filesystem with disconnected files and no /lost+found
directory
mke2fs2b.img Filesystem with corruption similar to that
created by mke2fs version 0.2b
noroot.img Filesystem with a deleted root directory
okgroup.img Filesystem that's exactly 8193 blocks long
(otherwise OK)
overfsblks.img Filesystem with overlapping inode and block bitmaps
symlinks.img Filesystem with bad symlink sizes