If the resize operation fails in the middle of the operation, mark the
filesystem as needing to be checked, and tell the user that they
should run e2fsck -fy on the device.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The resize2fs program was freeing the mountpoint information too
early, so garbage was getting printed instead of the correct
information in an error message.
Addresses-Debian-Bug: #535452
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Some people don't want to see the concise "kernel-style" make output.
This configure option allows build engines that want to see the full
set of commands executed by the makefile to get what they want. Most
people will find this more distracting than useful, unless they need
to debug the Makefiles.
(It is not necessary to rerun configure to enable this verbose make
output temprarily; if a developer wants to do a quick debug of a
directory's makefile, he or she can simply edit the definition of the
$(E) and $(Q) variables in the Makefile; instructions can be found in
the MCONFIG file which is included in at the beginning of every
Makefile.)
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The e2fsprogs makefiles were using the same Makefile variable
LIBCOM_ERR for the link-line arguments as well as the dependencies.
Since LIBCOM_ERR can now include non-file arguments such as
"-lpthread", we need to use a separate DEPLIBCOM_ERR variable that
only has build file dependencies.
Do the same thing for STATIC_LIBCOM_ERR and PROFILED_LIBCOM_ERR.
Addresses-Sourceforge-Patches: #2813809
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This was reported in Fedora, since the livecd creator does
a lot of resizing.
If we've moved the journal blocks during resize (more likely now,
due to the journal being in the middle) the backup blocks in the
superblock don't get updated, and a subsequent e2fsck will find
issues:
e2fsck 1.41.6 (30-May-2009)
Backing up journal inode block information.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/mnt/test/img: ***** FILE SYSTEM WAS MODIFIED *****
/mnt/test/img: 11/16000 files (0.0% non-contiguous), 17789/38400 blocks
This can be shown in a simple test:
# dd if=/dev/zero of=img bs=1 count=0 seek=3000M
# mke2fs -t ext4 -F img
# resize2fs img 150M
# e2fsck -f img
(thanks to the Fedora reporter Mads Kiilerich for the testcase!
https://bugzilla.redhat.com/show_bug.cgi?id=506105#c2)
So, update the backup journal in the superblock before resize2fs exits.
Addresses-RedHat-Bugzilla: #505339
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The e2fsprogs programs have historically just said that they operate
on ext2 and ext3 file system in their man pages. Update them to say
that they also operate on ext4 file systems.
Addresses-Launchpad-bug: #381854
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Without a force flag, don't allow resize2fs to even start resizing
below what it thinks the minimum safe value is.
This may stop resizes which could otherwise proceed with a bit
of space still left, but seems like a reasonably safe thing to do.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The extra padding added to the minimum size calculations:
/*
* We need to reserve a few extra blocks if extents are
* enabled, in case we need to grow the extent tree. The more
* we shrink the file system, the more space we need.
*/
if (fs->super->s_feature_incompat & EXT3_FEATURE_INCOMPAT_EXTENTS)
blks_needed += (fs->super->s_blocks_count - blks_needed)/500;
can go quite wrong if we've already added up more "blks_needed"
than our current size, and the above subtraction wraps. This can
easily happen for a filesystem which is almost completely full.
In this case, just return the current fs size as the minimum and
be done with it.
With this fix we could probably call calculate_minimum_resize_size()
for each resize2fs invocation and refuse to resize smaller than that?
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Resize2fs will attempt to truncate an image file of a filesystem down
to size for the convenience of the system administrator. If the
truncate operation fails, print a warning message. This also avoids a
gcc warning message.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Due to a fencepost bug, when skipping a block group whose block bitmap
was uninitialized (and hence could not contain any blocks eligible for
relaocation), the block immediately following the block group wasn't
checked as well. If it was in use and required relocation, it
wouldn't get properly relocated, with the result that an inode using
such a block would end up, post resize, with a pointer to a block now
outside the bounds of the filesystem.
This commit fixes this fencepost error.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If we need to shrink the inode table, we need to make sure the inodes
contained in the part of the inode table we are vacating don't get
reused as part of the filesystem shrink operation. This wasn't a
problem with ext3 filesystems, since the inode table was located in
the block group that was going away, so that location was not eligible
for reallocation.
However with ext4 filesystems with flex_bg enabled, it's possible for
a portion of the inode table in the last flex_bg group to be
deallocated, but in a part of the filesystem which could be used as
data blocks. So we must mark those blocks as reserved to prevent
their reuse, and adjust the minimum filesystem size calculation to
assure that we don't shrink a filesystem too small for the resize
operation to succeed.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
When allocating a new set of block group metadata as part of growing
the filesystem, the resize2fs code assumes that the bitmap and inode
table blocks are in their own block group; an assumption which is
changed by the flex_bg feature. This commit works around the problem
by temporarily turning off flex_bg while allocating the new block
group metadata, to avoid potentially overwriting previously allocated
data blocks.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Some extra blocks may be needed to expand some extent allocation trees
while we are shrinking the filesystem. We don't know exactly how
much, so we use a hueristic.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
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>
If we don't check for new_size == 0, bogus values send resize2fs into
a tailspin:
resize2fs 1.41.0 (10-Jul-2008)
Illegal block number passed to ext2fs_test_block_bitmap #1 for block bitmap for
/tmp/tmp.lntZtMFvz8/fake-disk
...the same message repeated zillion times...
Probably should see where that loop is, but at any rate we should
error-check parse_num_blocks.
Thanks to Petr Muller for reporting this.
Addresses-Red-Hat-Bugzilla: #465984
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Check the return value of ext2fs_get_mem, since prog isn't initialized
so checking may miss a failed memory allocation.
Signed-off-by: Manish Katiyar <mkatiyar@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
In order to make it possible for the test_io manager to be compiled in
by default, make all of the programs that might try to use it to only
do so if the environment variables TEST_IO_FLAGS and TEST_IO_DEBUG are
set.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The current method of adding one block group at a time to a mounted
filesystem means it is impossible to accomodate the flex_bg allocation
method of placing the metadata together in a single block group. For
now we "fix" this issue by using the traditional layout for new block
groups, where each block group is self-contained and contains its own
bitmap blocks and inode tables. This means we don't get the layout
advantages of flex_bg in the new block groups, but at least it allows
on-line resizing to function.
Long term, we will need to create a new ioctl which does much more of
the resizing work in the kernel.
We also fix a bug in the ext3/ext4 ioctl fallback code so we stop
trying the ext3 ioctl for every single block group when resizing an
ext4 filesystem.
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>
These were caused by multi-line strings missing a space at the line
break. Thanks to translator Phillipp Thomas for noticing these typo's.
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>
Allow the old name of uninit_groups when converting feature names for
backwards compatibility for scripts running mke2fs and tune2fs.
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>
Apparently Mac OS 10.5 defines fstat64(), but not ftruncate64(),
causing resize2fs to fail to build. So check explicitly for
ftruncate64(), and fall back to ftruncate() if necessary.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If we can't use ftruncate64(), and have to use ftruncate() instead,
make sure that we don't accidentally truncate the size when we chop it
down to an off_t before calling ftruncate(), lest we severely damage a
filesystem image file.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Valerie Aurora Henson