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>
Akira Fujita merged a patch into 2.6.33 that adds a requirement that a
file being defragged must be opened with read and write access, so
e2fsprogs needs to satisfy that.
Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
As recently discussed on linux-ext4@vger.kernel.org add an option to e2fsck
to allow to replay the journal only. That will allow scripts, such as
pacemakers 'Filesystem' RA to first replay the journal and if that sets
an error state from the journal replay, further check for that error
(dumpe2fh -h | grep "Filesystem state:") and if that shows and error
to refuse to mount. It also allows automatic e2fsck scripts to first
replay the journal and on a second run after the real pass1 to passX checks
to test for the return code.
Signed-off-by: Bernd Schubert <bschubert@ddn.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
If the user specifies "e2fsck -j UUID=XXX", e2fsck should do blkid
interpretation, since e2fsck does it with the base file system name.
So from the sake of consistency and user convenience, we should do it
here too.
Addresses-Debian-Bug: #559315
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The boolean options "force_no" in the problems stanza of e2fsck.conf
allows a particular problem code be treated as if the user will answer
"no" to the question of whether a particular problem should be fixed
--- even if e2fsck is run with the -y option.
As an example use case, suppose a distribution had widely deployed a
version of the kernel where under some circumstances, the EOFBLOCKS_FL
flag would be left set even though it should not be left set, and a
customer had a workload which exercised the fencepost error all the
time, resulting in many large number of inodes that had EOFBLOCKS_FL
set erroneously. Enough, in fact, the e2fsck runs were taking too
long. (There was such a bug in the kernel, which was fixed by commit
58590b06d in 2.6.36).
Leaving EOFBLOCKS_FL set when it should not be isn't a huge deal, and
is certainly than having high availability timeout alerts going off
left and right. So in this case, the best fix might be to put the
following in /etc/e2fsck.conf:
[problems]
0x010060 = { # PR_1_EOFBLOCKS_FL_SET
force_no = true
no_ok = true
no_nomsg = true
}
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
When running dumpe2fs on a filesystem formatted with flex_bg, it
prints out the relative offsets for the bitmaps and inode table
badly on 64-bit systems, because the offset is computed as a
large positive number instead of being a negative numer (which
will not be printed at all):
Group 1: (Blocks 0x8000-0xffff) [INODE_UNINIT, ITABLE_ZEROED]
Block bitmap at 0x0102 (+4294934786), Inode bitmap at 0x0202 (+4294935042)
Inode table at 0x037e-0x03fa (+4294935422)
This commit prints out the relative offsets for flex_bg
groups as the offset within the reported group. This makes it
more clear where the metadata is located, rather than simply
printing some large negative number.
Group 1: (Blocks 0x8000-0xffff) [INODE_UNINIT, ITABLE_ZEROED]
Block bitmap at 0x0102 (bg #0 +258), Inode bitmap at 0x0202 (bg #0 +514)
Inode table at 0x037e-0x03fa (bg #0 +894)
Signed-off-by: Andreas Dilger <adilger@dilger.ca>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If the user passes a file system type which is not defined in
mke2fs.conf (i.e., mke2fs -t xfs ...) change mke2fs so that it prints
a warning and aborts the run. (There is an exception for ext2, since
that file system does not need a special definition in the fs_types
section of the /etc/mke2fs.conf file.)
In addition, print a warning if there are usage types (specified using
the -T option) which are not defined in /etc/mke2fs.conf.
Addresses-Debian-Bug: #594609
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The dependency definitions for DEPSTATIC_LIBBLKID and
DEPPROFILED_LIBBLKID incorrectly referenced the non-dependency macros
(i.e., STATIC_LIBUUID instead of DEPSTATIC_LIBUUID). This resulted in
-luuid showing up as a Makefile dependency, which is of course wrong.
Addresses-Debian-Bug: #604629
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This fixes two possible causes for the error message:
WARNING: PROGRAMMING BUG IN E2FSCK!
OR SOME BONEHEAD (YOU) IS CHECKING A MOUNTED (LIVE) FILESYSTEM.
inode_link_info[X] is Y, inode.i_links_count is Z. They should be the same!
One cause which can trigger this message is when an inode has an
illegal link count > 65500 --- for example, 65535. This was the case
in the Debian Bug report #555456.
Another cause which could trigger this message is if an ext4 directory
previously had more than 65000 subdirectories (thus causing
i_link_count to be set to 1), but then some of the subdirectories were
deleted, such that i_link_count should now be the actual number of
subdirectories.
Addresses-Debian-Bug: #555456
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Clarify the e2fsck.conf(5) man page to make it clear that it applies
for ext4 file systems.
Addresses-Debian-Bug: #591083
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
There is generic discard function in struct_io_manager, or in
unix_io_manager to be specific. So use this instead of
mke2fs_discard_blocks().
Since mke2fs_discard_blocks() is not used anymore (and should not be)
remove it.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
In Pass 5 when we are checking block and inode bitmaps we have great
opportunity to discard free space and unused inodes on the device,
because bitmaps has just been verified as valid. This commit takes
advantage of this opportunity and discards both, all free space and
unused inodes.
I have added new set of options, 'nodiscard' and 'discard'. When the
underlying devices does not support discard, or discard ends with an
error, or when any kind of error occurs on the filesystem, no further
discard attempt will be made and the e2fsck will behave as it would
with nodiscard option provided.
As an addition, when there is any not-yet-zeroed inode table and
discard zeroes data, then inode table is marked as zeroed.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Kazuya Mio