On a very low-memory system, where ext2fs_check_desc() fails because
it can't allocate a block bitmap, catch this error and report it
immediate. This avoids something like this, which could scare and
mislead the user:
e2fsck: Group descriptors look bad... trying backup blocks...
Media was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Error allocating block bitmap (1): Memory allocation failed
e2fsck: aborted
Addresses-Debian-Bug: #509529
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The Linux kernel modules could be compressed, it means modules.dep
parser in libblid has to support .ko.gz extension too.
(Note, I've talked about this problem with Jon Masters and his
suggestion is to exec(/sbin/modinfo) rather than directly parse
modules.dep. BTW, the modules.dep file is deprecated.)
Address-Red-Hat-Bug: #518572
Signed-off-by: Karel Zak <kzak@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
For filesystms that have the extent feature enabled, we need to grab
the use EXT2_IOC_GETFLAGS so that we don't accidentally end up trying
to request clearing the EXT2_EXTENT_FL, which is not supported and
causes the tune2fs -j error out.
Also fix the error returning in ext2fs_add_journal_inode() so it
returns a proper error code if the fstat() or ioctl() calls fail.
Addresses-Launchpad-bug: #416648
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The feature name "extent" is documented in mke2fs.conf, although both
"extent" and "extents" are accepted by e2fsprogs.
Addreses-Debian-Bug: #540111
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This is necessary to preserve the i_size of the output file; otherwise
programs like e2fsck will complain that the filesystem has been
truncated.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
When increasing inode size if we find that the new block
that we needed to increase the inode table size is a bad
block we fail. This make sure we don't end up with a corrupt
file system when doing inode resize on a file system having
bad blocks.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
With file system formated for RAID arrays we can have inode bitmap
and block bitmap after inode table. Make sure we move them around
properly when doing inode resize.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This removes the metadata block bitmap and makes the error handling
simpler. It also check for the enospc with the correct number needed
blocks. Also added specific error messages. We need to run e2undo
only if we start modiyfing inode, group desc and inode table.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Very often all the block group descriptors will have bad checksums, so
don't force the user answer 'yes' many, many times.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If multiple blocks of a block group's inode table overlaps with other
file system blocks, only ask once for each block group.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If the filesystem feature FLEX_BG is enabled, the inode table and
bitmap blocks can be located anywhere in the inode table. So for
FLEX_BG filesystems, new_table_block() now tries allocate in the block
group's flex_bg first, and if there is no space in the local flex_bg,
then try to allocate from the whole filesystem.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The extent list header gets printed before we fall back to bmap:
# filefrag -v /mnt/test/bar
Filesystem type is: 58465342
File size of /mnt/test/bar is 12288 (3 blocks, blocksize 4096)
ext logical physical expected length flags <---- HERE
Discontinuity: Block 2 is at 17 (was 16)
/mnt/test/bar: 2 extents found
so delay printing it until we know fiemap is working.
(though ideally it'd be nice to have the same verbose output
regardless of the interface we used, I think).
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The fragmentation count in the bmap case seems to be
off by one:
/mnt/test/bar: 0 extents found
Addresses-Debian-Bug: #540376
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Fix a bug in e2freefrag where if the last free extent is at the very
end of the filesystem, it would be disregarded.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If the file system has a non-zero s_first_data_block, as is the case
when the block size is 1kb, e2freefrag would incorrectly try to
reference invalid data blocks in the block allocation bitmap.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
"Free chunks" is confusing since it has nothing to do with the
chunksize; use "free extents" instead.
Also add a missing newline in an error message.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Fixed a bug where e2fsck would report that last mount time was in the
future when it was really the last write time that was in the future.
Also, since people can't seem to believe that (a) their distribution
has buggy init scripts, or (b) their CMOS/RTC clock or backup battery
is dead, print the incorrect time and the current system time.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Extend the stat command to display more detailed extent information if
the file uses extent mapping instead of displaying the block map using
the block_iterate funtion.
Add the command dump_extents which displays even more detailed
information about an inode's extent tree.
This commit is an extension of a patch from Curt Wohlgemuth.
Signed-off-by: Curt Wohlgemuth <curtw@google.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
We are using a signed int to store a block number in
ext2fs_allocate_group_table. We don't actually do any computation or
comparisons using it, so it shouldn't cause any bugs, but it's
technically incorrect, and it's possible an overly clever compiler
might do something wrong with it.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Avoiding inserting a new extent if it is possible to merge the new
block to the beginning or the end of the previous or next extent.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Comment out less common debugging printf's, and fix some type
warnings. Add high-level debugging printf's for ext2fs_extent_goto(),
ext2fs_extent_insert(), ext2fs_extent_delete(), ext2fs_extent_replace()
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Commit 0dc291611 introduced a regression when unmapping the first
block in an extent. This caused e2fsck -fD to corrupt large
directories if the directory has to shrink by more than one block.
The problem was set_bmap should only go to a next leaf when setting a
first block in an extent, and not when it is unmapping the first block
in an extent.
Addresses-Debian-Bug: #537510
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If building with util-linux-ng, we will use the external libblkid and
libuuid, as well as disabling the internal fsck.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
These were found necessary to build on FreeBSD 6.4.
Signed-off-by: Matthias Andree <matthias.andree@gmx.de>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Unfortunately, distributions like Ubuntu seem to have buggy init
scripts that run e2fsck and mount the root filesystem before making
sure the system time and time zone is correctly set. As a result, a
filesystem's last write and last mounted time can be set in future.
The buggy_init_scripts configuration option will stop e2fsck from
aborting the boot process, but it also inhibits the superblock times
from getting fixed. This causes resize2fs to refuse to resize the
filesystem, even after running e2fsck on the file system. To deal
with this, we need to fix the superblock write times unconditionally.
Addresses-Launchpad-bug: #373409
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Theodore Ts'o