Previously resize2fs assumed that bitmap and inode table blocks were
always located in their respective block group. However, this is no
longer true with flex_bg. So it is necessary to check all of the
block groups which will be truncated to see if they have metadata
blocks that need to be marked as no longer being in use in the new,
shrunk filesystem.
This bug fixes resize2fs -M, which would otherwise fail because
without the released blocks, there would not be enough space in the
filesystem. This bug also avoids (mostly harmless) filesystem
corruptions reported by e2fsck regarding blocks marked in use but not
actually used (these being the bitmap and inode table blocks
associated with the truncated block groups).
Note: in theory it is possible to have block group N utilize bitmap
and inode table blocks in block group N+X with flex_bg. At the moment
neither mke2fs nor e2fsck will create filesystems like this, which is
good, because resize2fs doesn't handle this case correctly.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
In the function blocks_to_move(), when checking to see if a block
group's block bitmap is initialized, we need to check the old_fs's
block group descriptors, not the new file system's (already truncated)
group descriptor data structures. Otherwise we will end up
derferencing past the end of the array boundary, and the resulting
garbage value may indicate that the bitmap is uninitialized, and so
all of the blocks in that block group will be skipped, resulting in
some blocks not getting marked as needing relocation.
This showed up in the following test case:
mke2fs -t ext4 -b 1024 test.img 1048576
resize2fs test.img 80000
The journal inode after the resize operation looked like this:
debugfs: stat <8>
Inode: 8 Type: regular Mode: 0600 Flags: 0x80000
...
BLOCKS:
(IND):35385, (0-5836):2356-8192, (5837-21959):8454-24576, (21960-32506):24838-35
384, (32507-32767):434177-434437
TOTAL: 32769
The blocks 434177-434437 were not moved because block group 53 was
wrongly thought to have an unitialized block group.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Some of these could affect filesystems between 2^31 and 2^32-1 blocks.
Thanks to Valerie Aurora Henson for pointing out the problems in
lib/ext2fs/alloc_tables.c, which led me to do a "make gcc-wall" scan
over the source tree.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This fixes a cosemtic issue where we don't complete the progress bar
and issue a newline before printing the final resize successful
message.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
In the rare case where new blocks are needed while mutating an extent
tree, supply a specialized block allocator so that extent_node_split()
allocates valid blocks for the interior nodes of the extent tree.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If the filesystem has the uninit_bg feature, then parts of the block
and inode bitmap may not be initialized. Teach resize2fs how to deal
with these case appropriately. (Most of these fixes were fortunately
not necessary for the common case where the resize_inode is present to
reserve space, and where the filesystem is being expanded instead of
being shrunk.)
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
When moving directories into new block groups (which would only happen
when shrinking a filesystem), resize2fs would increase the directory
in-use count by 2 times the necessary value, due to a change in
ext2fs_inode_alloc_stats() made in e2fsprogs 1.26. This is largely
harmless, but it does result in a filesystem corruption for e2fsck to
fix.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If the filesystem is grown to the point where the resize_inode is no
longer needed, clean it up properly so e2fsck doesn't have to.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
When calculating the number reserved blocks, use floating point for
better accuracy, since for big filesystems it really makes a
difference. In addition, mke2fs and tune2fs accepts a floating point
number from the user, so they should provide that level of accuracy.
Addresses-Debian-Bug: #452639
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Add the -P option to print the minimum filesystem size and exit.
Add the -M option to force resizing the filesystem to the minimum
filesystem size.
Signed-off-by: Josef Back <jbacik@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Use ext2fs_get_next_inode_full() in resize2fs and clean up large inode
handling; previous attempt was not properly handling all cases, and
was incorrectly setting i_extra_isize. This caused some extended
attributes to get removed or randomly assigned to other inodes as a
result of the resize, which can be unfortunate on systems using
SELinux.
The previous commit didn't fix things completely on big-endian systems
like PowerPC.
Addresses-Red-Hat-Bugzilla: #434893
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
inode_scan_and_fix() in resize2fs needs to do read/write of the full
inode to be sure it gets all data from larger (>128 byte) inodes.
Addresses-Red-Hat-Bugzilla: #434893
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Add some additional checks, primarily in resize2fs and in the rarely
used (and soon to-be-deprecated) e2fsck byte-swap filesystem function.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Add macros to support variable-length group descriptors for ext4.
Signed-off-by: Valerie Clement <valerie.clement@bull.net>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This patch changes ext2fs_open() to set EXT2_FLAG_MASTER_SB_ONLY by
default. This avoids some problems in e2fsck (reported by Jim Garlick)
where a corrupt journal can end up writing the bad superblock to the
backups. In general, only e2fsck (after the filesystem is clean),
tune2fs, and resize2fs should change the backup superblocks by default.
Most callers of ext2fs_open() should not be touching anything where the
backups should be touched. So let's change the defaults to avoid
potential problems.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Found 2 of the three places where a return code for ext2fs_write_inode() was
not being checked.
The second fix in e2fsck/emptydir.c is basically just to shut coverity up even
though it really is unnecessary.
Coverity ID: 1: Checked Return
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Add a new functiom, e2p_percent(), which correct calculates the percentage
of a number based on a given percentage, without worrying about overflow
issues. This is used where we calculate the number of reserved blocks using
a percentage of the total number of blocks in a filesystem.
Based on patches from Eric Sandeen, but generalized to use this new function.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Eric Sandeen <esandeen@redhat.com>
For loops such as:
for (i=1; i <= fs->super->s_blocks_count; i++) {
<do_stuff>
}
if i is an int and s_blocks_count is (2^32-1), the condition is never false.
Change these loops to:
for (i=1; i <= fs->super->s_blocks_count && i > 0; i++) {
<do_stuff>
}
to stop the loop when we overflow i
Signed-off-by: Eric Sandeen <esandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Add a new function, ext2fs_div_ceil(), which correctly calculates a division
of two unsigned integer where the result is always rounded up the next
largest integer. This is used everywhere where we might have
previously caused an overflow when the number of blocks
or inodes is too close to 2**32-1.
Based on patches from Eric Sandeen, but generalized to use this new function
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Eric Sandeen <esandeen@redhat.com>
Change the format string(%d, %ld) for a block number and inode number
to %u or %lu.
Signed-off-by: Takashi Sato <sho@tnes.nec.co.jp>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
There was a off-by-one fencepost error in the logic used to check if
we avoid copying zero-filled blocks when moving an inode table down by
a block or two. Thanks to valgrind for catching it. As far as I know
this fencepost error wasn't causing any actual problems, but it was
definitely a bug.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
non-empty bad block list. Resize2fs now discards any blocks on the
badblock list which are no longer part of the filesystem as the result
of a filesystem shrink. (Note: this means that shrinking and then
enlarging a filesystem is no longer a reversible operation;
information about bad blocks in the part of the filesystem
which is to be chopped off will be lost.)
moving an inode, set the ctime field so that people using
dump/restore will backup the changed inode. Also update
the mtime and ctime of directories which get updated when
we need to move an inode.
release the bmap table. This significantly speeds up
resize2fs when shrinking or expanding a filesystem by a
very small number of blocks (which EVMS will do).
Theodore Ts'o