Enhance the online resizing code to be more nuanced about resizing
restrictions. If the kernel supports meta_bg resizing, then we can
skip all of the restrictions. If the kernel does not support meta_bg
resizing, check more carefully to make sure there are enough reserved
gdt blocks, so that the user gets a clearer error message.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Linux's compat_sys_ioctl() function, which is run when executing a
ioctl using a 32-bit binary on a 64-bit kernel, returns EINVAL when an
inode does not exist. Sigh. See /usr/src/linux/fs/compat_ioctl.c.
This is probably a kernel bug, but work around it for now.
Addresses-Debian-Bug: #644989
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Commit 9f6ba888f0 added support for new online resize ioctl
EXT4_IOC_RESIZE_FS. It is also trying to avoid failure when this
ioctl() is not supported by the kernel however it is checking wrong
error code (EINVAL).
When the ioctl does not exist, errno is set to ENOTTY, so we should
check for that, rather than EINVAL which means that ioctl arguments
are not valid. So change the code to check for ENOTTY and allow
resize2fs to try to use the old approach. Also add some comments.
Addresses-Red-Hat-Bugzilla: #746284
Addresses-Debian-Bug: #644989
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
On-line resizing has been broken in the 1.42 series for two reasons:
(a) the call to the new EXT4_IOC_RESIZE_FS ioctl checked for ENOTTY to
indicate that the ioctl does not exist, when in fact EINVAL is what is
returned if the ioctl doesn't exist. (b) resize2fs was passing in a
pointer to a 64-bit value, when the ioctl expected a 32-bit value.
This was OK on little-endian systems, but it wouldn't work at all on
big-endian systems.
Fix both problems.
Addresses-Debian-Bug: #451388
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The DEFS line in MCONFIG had gotten so long that it exceeded 4k, and
this was starting to cause some tools heartburn. It also made "make
V=1" almost useless, since trying to following the individual commands
run by make was lost in the noise of all of the defines.
So fix this by putting the configure-generated defines in lib/config.h
and the directory pathnames to lib/dirpaths.h.
In addition, clean up some vestigal defines in configure.in and in the
Makefiles to further shorten the cc command lines.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Code to count the number of blocks in the last partial
group is cut and pasted around the e2fsprogs codebase
a few times.
Making this a helper function should improve matters.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This is needed to support online resizing for > 32-bit file systems
Signed-off-by: Yongqiang Yang <xiaoqiangnk@gmail.com>
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>
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>
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>
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>
Check to make sure the filesystem has a resize inode if it is needed to
grow the filesystem. Print the correct error message if the kernel
returns an ENOTTY error to the group extend ioctl
Addresses Debian Bug: #380548
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
There were still some %d's lurking when we print blocks & inodes; also
many of the counters in the e2fsck_struct were signed, and probably
need to be unsigned to avoid overflows.
Signed-off-by: Eric Sandeen <esandeen@redhat.com>
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>