This fixes a regression introduced in commit 79a9ab14 which caused
attempts to open external journals to fail due to overly strict
filesystem consistency checks.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
In Red Hat bug #481620 Jerry reported that the libext2fs info page
is not accesable via "info libext2fs" but is via "info libext2fs.info"
and suggested that the following change should fix it.
Additional info from Jerry:
The problem is that makeinfo 4.12 interprets the dot in "libext2fs.info"
to be the end of the description portion of the info entry, even though
it hasn't seen the closing parenthesis yet. Making the reference be to
just "libext2fs" works.
Addresses-Red-Hat-Bugzilla: #481620
Reported-by: Jerry James <loganjerry@gmail.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This is a regression from commit
8fdf29117f, which attempts to access
current_fs via a feature check before we check that it's open.
Just moving the feature check below the open check should fix it.
Reported-by: Andrew Hecox <ahecox@redhat.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The Lifetime writes field will probably not be stable as we add new
features to e2fsprogs, so filter it out to avoid spurious test failures.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Starting in 2.6.29, ext4 can be used to support filesystems without a
journal. So if ext2 is not present, and the kernel version is greater
than 2.6.29, and ext4 is present, return a filesystme type of ext4.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
ext4/ext4dev no longer require a journal.
w/o this blkid doesn't recognize after:
# mkfs.ext4 /dev/blah
# tune2fs -O ^has_journal
# blkid /dev/blah
We still must have one ext3-incompat-feature to flag
as ext4(dev) so we shouldn't ever mis-recognize it.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Nice for testing w/o needing to swizzle around system
libraries...
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The coverity scanner found this one.
If a line in modules.dep has a ":" but no "/" then:
if ((cp = strchr(buf, ':')) != NULL)
*cp = 0;
else
continue;
if ((cp = strrchr(buf, '/')) != NULL)
cp++;
/* XXX else cp is still null */
i = strlen(cp);
... we will deref a null pointer (cp). This can be
demonstrated by putting a line like:
foo.ko:
into modules.dep. The below change just says that if no "/" is
found, treat the whole string as the module name.
Addresses-Red-Hat-Bugzilla: #486997
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Add a check to make sure the argument to the -m option (which
specifies the reserved ratio) is greater than zero.
Addresses-Debian-Bug: #517015
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This field tracks the lifetime amount of writes to the filesystem. It
will be updated by the kernel as well as by e2fsprogs programs which
write to the filesystem.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The other problem codes associated with failing to create the
lost+found directory are non-fatal, and this one should be non-fatal
as well. The two places which call e2fsck_get_lost_and_found()
already deal with a failure to create the directory, so there's no
point making this be a fatal error.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If ext2fs_inode_alloc_stats2() or ext2fs_block_alloc_stats() is passed
an insanely large inode or block number, it's possible for these
functions to overrun an array boundary and cause the calling program
to crash with a memory error.
Detect this case, and since these functions don't return an error
code, print a warning message, much like we do in ext2fs_warn_bitmap2().
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Add a sanity check to makesure that even if the superblock field
s_first_inode is insane, that we won't return an invalid inode number.
(The function will return the error EXT2_ET_INODE_ALLOC_FAIL in that
case.)
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
An deliberately corrupted filesystem with an insanely large
s_first_ino field could cause e2fsck to crash with a seg fault.
Thanks to Eric Sesterhenn for supplying test cases which demonstrated
this issue.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The previous patch would return EFBIG for any failure called from
ext2fs_get_device_size2(). (I didn't merge this fix with the
preceeding commit to allow merges to happen more easily.)
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Gcc is too stupid to realize that:
const char *usage="String which has no percent signs";
com_err(progname, 0, usage);
is OK. I refuse to bow to stupidity with:
com_err(progname, 0, "%s", usage);
but I will use the string directly for the sake of people who like to
build with -Werror=format-security.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Mandriva apparently uses "mke3fs" as an alias for mkfs.ext3. I'm not
particularly fond of that practice, but we'll include it as legacy
support.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If a filesystem is built with the stride extended-option (which is
often used in RAID filesystems to make sure the block and inode
allocation bitmaps don't end up hitting one disk platter harder than
the rest), this can cause tune2fs -I to corrupt the filesystem because
it fails to handle the case where the allocation bitmaps are located
after the inode table, where the inode table needs to grow. Handle
this case correctly.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
With flex_bg usually the inode table for most block groups are packed
right against each other, so expanding the inode table size needs
special handling that's not currently in tune2fs.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Add btrfs detection to libblkid, now that the disk format should be
recognizable in the future.
# misc/blkid /tmp/fsfile
/tmp/fsfile: LABEL="mylabel" UUID="102b07f0-0e79-4b42-8a4e-1dde418bbe6d" TYPE="btrfs"
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Some extra blocks may be needed to expand some extent allocation trees
while we are shrinking the filesystem. We don't know exactly how
much, so we use a hueristic.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
When modifying a block via the block_iterate interface, preserve the
uninit flag in the extent. Resize2fs uses this interface, so we have
to preserve the uninit status when relocating a block.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If the callback function tries to change a block, and
ext2fs_extent_set_bmap() fails for some reason (for example, there
isn't enough disk space to split a node and expand the extent tree,
make sure that error is reflected back up to the caller.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Previously resize2fs assumed that bitmap and inode table blocks were
always located in their respective block group. However, this is no
longer true with flex_bg. So it is necessary to check all of the
block groups which will be truncated to see if they have metadata
blocks that need to be marked as no longer being in use in the new,
shrunk filesystem.
This bug fixes resize2fs -M, which would otherwise fail because
without the released blocks, there would not be enough space in the
filesystem. This bug also avoids (mostly harmless) filesystem
corruptions reported by e2fsck regarding blocks marked in use but not
actually used (these being the bitmap and inode table blocks
associated with the truncated block groups).
Note: in theory it is possible to have block group N utilize bitmap
and inode table blocks in block group N+X with flex_bg. At the moment
neither mke2fs nor e2fsck will create filesystems like this, which is
good, because resize2fs doesn't handle this case correctly.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
In the function blocks_to_move(), when checking to see if a block
group's block bitmap is initialized, we need to check the old_fs's
block group descriptors, not the new file system's (already truncated)
group descriptor data structures. Otherwise we will end up
derferencing past the end of the array boundary, and the resulting
garbage value may indicate that the bitmap is uninitialized, and so
all of the blocks in that block group will be skipped, resulting in
some blocks not getting marked as needing relocation.
This showed up in the following test case:
mke2fs -t ext4 -b 1024 test.img 1048576
resize2fs test.img 80000
The journal inode after the resize operation looked like this:
debugfs: stat <8>
Inode: 8 Type: regular Mode: 0600 Flags: 0x80000
...
BLOCKS:
(IND):35385, (0-5836):2356-8192, (5837-21959):8454-24576, (21960-32506):24838-35
384, (32507-32767):434177-434437
TOTAL: 32769
The blocks 434177-434437 were not moved because block group 53 was
wrongly thought to have an unitialized block group.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
E2fsck was using a fixed-size 8k buffer for replaying blocks from the
journal. So attempts to replay a journal on filesystems greater than
8k would cause e2fsck to crash with a segfault.
Thanks to Miao Xie <miaox@cn.fujitsu.com> for reporting this problem.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The ext4 filesystem uses journals too, so remove "ext3" from the
problem descriptions involving journals.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This test case is designed to test e2fsck's ability to deal with a
corrupted interior node in an extent tree.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
A corrupted interior node in an extent tree would cause e2fsck to
crash with the error message:
Error1: Corrupt extent header on inode 107192
Aborted (core dumped)
Handle this and related failures when scanning an inode's extent tree
more robustly.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If the directory is packed with no slack space, as soon as any new
directory entries are added, leaf nodes end up getting split and
directory ends up getting very inefficient.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Theodore Ts'o