Currently, e4defrag always does byte-swapping when it gets superblock
information, so the calculation of the best extents count is not
correct on little endian machine. This doesn't cause data corruption,
but it may confuse users by showing the wrong extent count. To solve
this problem, we use ext2fs_open() instead of get_superblock_info()
that is the original function.
Signed-off-by: Kazuya Mio <k-mio@sx.jp.nec.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
If a file gets deleted or truncated while e4defrag is trying to
operate on it, it's possible for it seg fault.
Addresses-Red-Hat-Bugzilla: #641926
Reported-by: Michal Piotrowski <mkkp4x4@gmail.com>
Signed-off-by: Kazuya Mio <k-mio@sx.jp.nec.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If the file system size was not specified on the command line, we were
always using the usage type "floppy" since we didn't determine the
device size until after calling parse_fs_types(). Doh!
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>
If the file system has a blocksize less than 64k, then don't use the
extended rec_len encoding, to be consistent with what the kernel will
do.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
ext2fs_zero_block2() allocates static buffer if needed so it
should be freed at last (call it again with 0 args).
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Avoid memory leaks on error paths, and make sure we issue the correct
error messages in the case of (highly) unlikely errors.
Original patch submitted by Namhyung Kim <namhyung@gmail.com>, but
highly rewritten since then.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Check return value of some functions and exit if unhandled error occurred.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
In original code, 'huge' type could not be selected because it
always be caught for 'big' type. Change the ordering.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The commit 493024ea1d ("mke2fs: Fix up the
fs type and feature selection for 64-bit blocks") added 'big' and 'huge'
usage-type but was missing description in man page. Add it.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
... in the very unlikely case that e2p_os2string fails to allocate
memory.
Reported-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
There was a potential of freeing an uninitialized pointer in
rec.block_buf, which was pointed out by Namhyung Kim <namhyung@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This fixes following build failure when OMIT_COM_ERR is defined:
lib/ext2fs/gen_bitmap.c: In function ‘ext2fs_clear_generic_bitmap’:
lib/ext2fs/gen_bitmap.c:437: error: invalid storage class for function ‘ext2fs_test_clear_generic_bitmap_range’
lib/ext2fs/gen_bitmap.c:559: error: expected declaration or statement at end of input
lib/ext2fs/gen_bitmap.c: In function ‘ext2fs_get_generic_bitmap_end’:
lib/ext2fs/gen_bitmap.c:559: error: expected declaration or statement at end of input
lib/ext2fs/gen_bitmap.c: In function ‘ext2fs_get_generic_bitmap_start’:
lib/ext2fs/gen_bitmap.c:559: error: expected declaration or statement at end of input
lib/ext2fs/gen_bitmap.c: In function ‘ext2fs_unmark_generic_bitmap’:
lib/ext2fs/gen_bitmap.c:559: error: expected declaration or statement at end of input
lib/ext2fs/gen_bitmap.c: In function ‘ext2fs_mark_generic_bitmap’:
lib/ext2fs/gen_bitmap.c:559: error: expected declaration or statement at end of input
lib/ext2fs/gen_bitmap.c: In function ‘ext2fs_test_generic_bitmap’:
lib/ext2fs/gen_bitmap.c:559: error: expected declaration or statement at end of input
make[2]: *** [gen_bitmap.o] Error 1
make[2]: Leaving directory e2fsprogs/lib/ext2fs'
make[1]: *** [all-libs-recursive] Error 1
make[1]: Leaving directory e2fsprogs'
make: *** [all] Error 2
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The fallocate() interface on 32-bit machines is defined to use off_t,
not loff_t (even though the system call interface is 64-bit clean).
This causes e4defrag to fail on files greater than 2GB. Fix this by
trying to use fallocate64(), and using the hard-coded syscall if it
does not exist.
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>
Flags used during RHEL/Fedora builds lead to a couple type-punning
warnings:
recovery.c: In function 'do_one_pass':
recovery.c:539: warning: dereferencing type-punned pointer will break strict-aliasing rules
./csum.c: In function 'print_csum':
./csum.c:170: warning: dereferencing type-punned pointer will break strict-aliasing rules
The two changes below fix this up.
Note that the csum test binary output changes slightly, but this does
not break any tests.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Add the description of the size per one extent and the maximum extent size
in ext4 into e4defrag man page.
Signed-off-by: Kazuya Mio <k-mio@sx.jp.nec.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
If non-privileged user runs e4defrag, e4defrag returns an exit status
of 1 despite its success. This patch fixes this problem.
Signed-off-by: Kazuya Mio <k-mio@sx.jp.nec.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
e4defrag uses st_blocks (struct stat) to calculate file blocks. However,
st_blocks also has meta data blocks in addition to file blocks. So, we
calculate file blocks by sum of the extent length.
Signed-off-by: Kazuya Mio <k-mio@sx.jp.nec.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
e4defrag with -c option outputs "ratio" that means the levels of
fragmentation. However, it's difficult for users to understand, so we will
use size per extent instead of ratio.
Before:
# e4defrag -c /mnt/mp1/file
<File> now/best ratio
/mnt/mp1/file 6/1 0.00%
Total/best extents 6/1
Fragmentation ratio 0.00%
Fragmentation score 0.04
[0-30 no problem: 31-55 a little bit fragmented: 55- needs defrag]
This file(/mnt/mp1/file) does not need defragmentation.
Done.
After:
# e4defrag -c /mnt/mp1/file
<File> now/best size/ext
/mnt/mp1/file 6/1 16666 KB
Total/best extents 6/1
Average size per extent 16666 KB
Fragmentation score 0
[0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]
This file (/mnt/mp1/file) does not need defragmentation.
Done.
Signed-off-by: Kazuya Mio <k-mio@sx.jp.nec.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Currently e4defrag relies on the EXT4_IOC_MOVE_EXT ioctl to perform online
defragmentation. However, this iotcl kernel patch is not available before
2.6.30-rc1. e4defrag shall fail without obvious reasons on systems running
older kernels. The patch adds more detailed error message addressing this
issue and prompts users with the minimal kernel version that is needed to
run e4defrag.
Signed-off-by: Peng Tao <bergwolf@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Theodore Ts'o