The write_journal_inode() code is only setting the low 32-bit i_size
for the journal size, even though it is possible to specify a journal
up to 10M blocks in size. Trying to create a journal larger than 2GB
will succeed, but an immediate e2fsck would fail. Store i_size_high
for the journal inode when creating it, and load it upon access.
Use s_jnl_blocks[15] to store the journal i_size_high backup. This
field is currently unused, as EXT2_N_BLOCKS is 15, so it is using
s_jnl_blocks[0..14], and i_size is in s_jnl_blocks[16].
Rename the "size" argument "num_blocks" for the journal creation functions
to clarify this parameter is in units of filesystem blocks and not bytes.
Signed-off-by: Andreas Dilger <adilger@whamcloud.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
I ran into odd behavior where mkfs.ext4 of a 16T filesystem would
create a resize inode with 0 reserved blocks, and mark the resize_inode
feature.
A subsequent slight downward resize of the filesystem would remove
the resize inode, making any further offline resizing impossible.
This is especially odd in light of the fact that a large downward
resize (say, to 8T) will actually add blocks to the resize inode -
so a small resize removes it, a large resize expands it ...
commit 8ade268cf2 had added this:
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.
but, it seems e2fsck does not care about this situation, either.
So, simply leave the resize_inode intact in this case, and everything
seems to be happy.
Note, this is for the 1.41.xx branch.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Before we go whole-hog on 64-bit e2fsprogs, I wonder if this
is worth considering as a last-minute addition to the 1.41
stream. Currently, mke2fs will shave a block off an exactly-16T
device to fit*, but resize2fs does not do the same, leading
to some asymmetry. This patch fixes that up, and allows 16T
devices to be handled more gracefully in offline resize.
(in fact resize2fs will not even open a 16T device, today).
*commit 37d17a65ec
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Requiring an immediate pre-fsck before printing a minimum
resize size seems a bit draconian; if the fs isn't clean or marked
with error, then certainly, but for an informational minimum
size, I don't think we need to require a fsck since last mount.
I had simply copied the checks from the actual resize path,
previously.
Installers use this option (-P) to gather minimum resize info,
and requiring an actual fsck before use just seems to go too far.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Commit 641b66b fixed a floating point precision error which can result
in a search algorithm looping forever. It can also result in an array
index being out of bounds and causing a segfault. Here are two more
cases in e2fsck and resize2fs that need to be fixed. I've just used
the same fix from the that commit.
Signed-off-by: Lachlan McIlroy <lmcilroy@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Right now, resize2fs -P on a dirty filesystem will give you a number;
however, it's probably wrong if the fs is not clean:
# resize2fs -P myimage.img
resize2fs 1.41.9 (22-Aug-2009)
Estimated minimum size of the filesystem: 75623
# e2fsck -fy myimage.img
e2fsck 1.41.9 (22-Aug-2009)
myimage.img: recovering journal
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
myimage.img: ***** FILE SYSTEM WAS MODIFIED *****
myimage.img: 9530/53760 files (0.1% non-contiguous), 24737/98304 blocks
# resize2fs -P myimage.img
resize2fs 1.41.9 (22-Aug-2009)
Estimated minimum size of the filesystem: 32165
We should issue the same "Please run e2fsck ..." message for
-P as we do for an actual resize request.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Commit 74128f8 added tests for uninit groups, but it could access past
the end of the group_desc[] array after processing the last group:
==19668== Invalid read of size 2
==19668== at 0x40518C: resize_fs (resize2fs.c:1824)
==19668== by 0x405A46: main (main.c:451)
==19668== Address 0x5a0d002 is not stack'd, malloc'd or (recently) free'd
==19668==
==19668== Invalid read of size 2
==19668== at 0x405391: resize_fs (resize2fs.c:1864)
==19668== by 0x405A46: main (main.c:451)
==19668== Address 0x5a0d002 is not stack'd, malloc'd or (recently) free'd
==19668==
It was found by Eric Sandeen running the regression suite through
valgrind.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Resizing a filesystem with an external journal fails when it tries
to read inode 0:
# touch testfs
# truncate testfs 1342177280
# touch testjournal
# truncate testjournal 134217728
# mke2fs -O journal_dev testjournal
# losetup /dev/loop0 testjournal
# mkfs.ext4 -J device=/dev/loop0 testfs 127680
# resize2fs testfs
resize2fs 1.41.9 (22-Aug-2009)
Resizing the filesystem on testfs to 327680 (4k) blocks.
resize2fs: Illegal inode number while trying to resize testfs
Please run 'e2fsck -fy testfs' to fix the filesystem
after the aborted resize operation.
I think the right, simple thing to do is just bail out early
for an external journal here, as there are no backup blocks
to update.
Reported-by: mjevans1983@gmail.com
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
After cleaning up ext2fs_bg_flag_set() and ext2fs_bg_flag_clear(),
we're left with ext2fs_bg_flag_test(). Convert it to
ext2fs_bg_flags_test().
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The ext2fs_bg_flag* functions were confusing.
Currently we have this:
void ext2fs_bg_flags_set(ext2_filsys fs, dgrp_t group, __u16 bg_flags);
void ext2fs_bg_flags_clear(ext2_filsys fs, dgrp_t group,__u16 bg_flags);
(_set (unused) sets exactly bg_flags; _clear clears all and ignores bg_flags)
and these, which can twiddle individual bits in bg_flags:
void ext2fs_bg_flag_set(ext2_filsys fs, dgrp_t group, __u16 bg_flag);
void ext2fs_bg_flag_clear(ext2_filsys fs, dgrp_t group, __u16 bg_flag);
A better interface, after the patch below, is just:
ext2fs_bg_flags_zap(fs, group) /* zeros bg_flags */
ext2fs_bg_flags_set(fs, group, flags) /* adds flags to bg_flags */
ext2fs_bg_flags_clear(fs, group, flags) /* clears flags in bg_flags */
and remove the original ext2fs_bg_flags_set / ext2fs_bg_flags_clear.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This commit forces the use of the system-provided blkid or uuid header
files if we are using the system-provided blkid or uuid libraries.
This avoids using the in-tree header files with the system libraries.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
When flex_bg is on, calculate_minimum_resize_size() should add more meta
blocks for newly added flex_bg.
Addresses-RedHat-Bugzilla: #519131
Signed-off-by: Peng Tao <bergwolf@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
When running resize2fs -M, no need to recalculate the minimal fs size.
Signed-off-by: "Peng Tao" <bergwolf@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
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>
Andreas Dilger