To make it easier to maintain changes and fixes to the e4defrag
program, check it into the e2fsprogs source tree.
Signed-off-by: Akira Fujita <a-fujita@rs.jp.nec.com>
Signed-off-by: Takashi Sato <t-sato@yk.jp.nec.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
e2fsck_pass5() checks whether the inode and block allocation bitmaps
are consistent. However, if EXT2_BG_[INODE/BLOCK]_BITMAP is set to a
ext4's block group, most of its bitmap is uninitialized (0). In that
case, we can optimize e2fsck's pass 5 by checking the entire range of
an uninitalized block group instead of checking bit by bit.
This can speed up e2fsck pass 5 by up to 80%:
+-----+--------------------+--------------------+
| | old e2fsck | new e2fsck |
|Pass | time(s) | time(s) |
| | real | user |system| real | user |system|
+-----+------+------+------+------+------+------+
| 1 | 5.70| 3.29| 0.50| 5.66| 3.21| 0.54|
| 2 | 3.33| 0.80| 0.19| 3.40| 0.82| 0.23|
| 3 | 0.01| 0.00| 0.00| 0.01| 0.00| 0.00|
| 4 | 1.04| 1.04| 0.00| 1.05| 1.04| 0.00|
| 5 | 19.60| 17.27| 0.06| 3.53| 1.21| 0.05|
+-----+------+------+------+------+------+------+
|Total| 29.94| 22.57| 0.80| 13.90| 6.47| 0.86|
+-----+------+------+------+------+------+------+
Comparison of e2fsck time on an ext4 500GB partition (20% blocks used)
Machine environment:
CPU: Intel(R) Xeon(TM) CPU 3.00GHz
Memory: 1GB
Kernel: linux-2.6.29-git2
Signed-off-by: Kazuya Mio <k-mio@sx.jp.nec.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Optimize ext2fs_test_block_bitmap_range() and add a new function,
ext2fs_test_inode_bitmap_range(), which works the same way as
ext2fs_block_bitmap_range() but for inode bitmaps. It's needed for
some code in the development branch, so let's drop it into the maint
branch to make life easier in the future.
Signed-off-by: Kazuya Mio <k-mio@sx.jp.nec.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Commit 53422e moved the new extent insertion in
ext2fs_extent_set_bmap() prior to the modification of the original
extent, but the insert function left the handle pointing to the new
extent. This left us modifying the -new- extent, instead of the
original one, and winding up with a corrupt extent tree something
like:
BLOCKS:
(0-1):588791-588792, (0):588791
We need to move back to the previous extent prior
to modification, if we inserted a new one.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
check_block_bitmap() calculates the block number of superblock in the current
block group but it's not used.
Signed-off-by: Kazuya Mio <k-mio@sx.jp.nec.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
If unused range of the bitmap has an unmarked bit, check_[inode/block]_end()
marks all bits in the range. However, we know that the checked bits are marked.
So this patch fixes loop counter to mark from the unmarked bit.
Signed-off-by: Kazuya Mio <k-mio@sx.jp.nec.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Remove the continue statement because it calls at the end of the loop.
Signed-off-by: Kazuya Mio <k-mio@sx.jp.nec.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
If gmake is available, the developer can use "make V=1" instead of
using a configure-time switch, --enable-verbose-makecmds, to see all
of the commands executed by the Makefile.
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>
When used with -v and the targeted file has more than 144
extents(double of the length of fm_extents array provided by buf),
filefrag_fiemap loops and calls fiemap ioctl() multiple times to
calculate the actual number of extents in a file. Each call to fiemap
ioctl() uses fm_start as the starting logical offset. The patch fixes
fm_start in each loop( except for the first one) and makes the extent
calculation correct for files with more that 144 extents.
To produce the problem, first run filefrag -v on a highly fragmented
file. Then change the buf size in filefrag_fiemap to make it large
enough to have all the extent mapped in a single loop and run filefrag
-v after recompiling. The former will produce a much smaller extent
count because of the false fm_start used in the loop. And the two will
produce different extent output since the 145th extent.
Signed-off-by: Peng Tao <bergwolf@gmail.com>
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>
The MCONFIG.in file used $(LIBUUID) in the definition of DEPLIBBLKID,
when it should have used $(DEPLIBUUID) instead.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Some distributions don't like installing uuidd setuid or setgid. So
if the setuid or setigid bit is not set with uuidd, and the current
process does not have write access to the UUIDD work directory, don't
try running uuidd, since it won't work properly.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If for some reason the uuidd daemon or the process calling uuidd
exited unexpectely, the read_all() function would end up looping
forever, either in uuidd or in libuuid. Fix this terminating the loop
if no data can be read after five tries to read from the file
descriptor.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
In the event that file descriptors 0-2 are closed when uuidd is
started, the server socket could be created as a file descriptor that
will get closed when create_daemon() tries detaching the uuidd daemon
from its controlling tty. Avoid this case by using dup(2).
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
When closing all of the file descriptors before starting uuidd, make
sure file descriptors 0, 1, and 2 are reserved by opening /dev/null.
This prevents strange bugs caused by assumptions regarding file
descriptors <= 2 as being special.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Some terminal programs may print wierd characters when they see the
\001 or \002 characters. So filter them out if the -s option
(skip_mode) is enabled.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
ext2fs_validate_entry would read beyond the end of the block to get
dirent->rec_len for certain arguments (like if blocksize ==
final_offset). This patch adds a check so that doesn't happen, and
changes the types of the arguments to avoid a compiler warning.
Signed-off-by: Nic Case <number9652@yahoo.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
do_logdump may jump to errout if fopen(out_file) fails,
but in that case out_file is NULL, and fclose will segfault.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Add an option to switch between the private (in-tree) libuuid and
public (in-system installed) library. The private version is still
enabled by default.
Signed-off-by: Scott James Remnant <scott@netsplit.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
lsattr doesn't return an error if you point it at a file that
doesn't exist.
This is slightly trickier because it can take more than one
file as an arg, but ls seems to report an error if any occurred,
so this does the same, it'll report the last error that was
encountered.
Addresses-RedHat-Bugzilla: #489841
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Previously e2fsprogs interpreted 0 for a rec_len of 65536 (which could
occur if the directory block is completely empty in 64k blocksize
filesystems), while the kernel interpreted 65535 to mean 65536. The
kernel will accept both to mean 65536, and encodes 65535 to be 65536.
This commit changes e2fsprogs to match.
We add the encoding agreed upon for 128k and 256k filesystems, but we
don't enable support for these larger block sizes, since they haven't
been fully tested.
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>
I noticed that neither the journal nor resize inodes have
i_extra_isize set post-mkfs; while this isn't likely
to be a big problem, I think the below patch tidies
it up.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The ext2_extent_handle only has a struct ext2_inode allocated on
it, and the same amount copied into it in that same function,
but in update_path() we're possibly writing out more than that -
for example 256 bytes, from that address. This causes uninitialized
memory to get written to disk, overwriting the parts of the
inode past the osd2 member (the end of the smaller structure).
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Each time an extent handle is opened and closed, if the inode has an
extent tree which does not fit in the inode's i_block structure, a
filesystem block buffer was not getting released. Since e2fsck opens
an extent handle for every inode using extents, this can translate to
a very large amount of memory getting lost.
Thanks to Henrik 'Mauritz' Johnson for discovering and pointing out
this leak, which he ran into while running the "rdump" command in
debugfs.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>