Now that libext2fs marks group metadata in the fs block bitmap, adjust
the expected test output to reflect expanded use of block_uninit and
the fact debugfs no longer prints block bitmap data that fails to
account for group data blocks.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Since the beginning of the uninit_bg feature, the kernel[1] and
e2fsck[2] have always been careful to detect the presence of the
BLOCK_UNINIT flag, and compute a block bitmap with any group metadata
blocks marked in that bitmap. With that in mind, I think it's safe to
say that this is a design feature of uninit_bg.
Now that we've trained libext2fs to have this same behavior whenever
it's loading a block bitmap, we no longer need to unset BLOCK_UNINIT
for a group that contains only its own group metadata -- kernel,
e2fsck, and e2fsprogs will handle this correctly.
[1] kernel git 717d50e4971b81b96c0199c91cdf0039a8cb181a
"Ext4: Uninitialized Block Groups"
[2] e2fsprogs git f5fa20078b
"Add support for EXT2_FEATURE_COMPAT_LAZY_BG"
Reported-by: Akira Fujita <a-fujita@rs.jp.nec.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Since libext2fs now detects a BLOCK_UNINIT group and calculates the
group's block bitmap, we no longer need to emulate this behavior in
e2fsck. We can simply compare the found block map against the
filesystem's, and proceed from there.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The kernel[1] and e2fsck[2] both react to a BLOCK_UNINIT group by
calculating the block bitmap that's needed to show all the group
blocks for that group (if any) and using that. However, when reading
bitmaps from disk, libext2fs simply imports a block of zeroes into the
bitmap, without bothering to check for group blocks. This erroneous
behavior results in the filesystem having a block bitmap that does not
accurately reflect disk contents, and worse yet makes it seem as
though superblocks, group descriptors, bitmaps, and inode tables are
"free" space on disk.
So, fix the block bitmap loading routines to calculate the correct
block bitmap for all groups and load it into the main fs block bitmap.
This also fixes bogus debugfs output such as:
Group 1: (Blocks 8193-16384) [INODE_UNINIT, BLOCK_UNINIT]
Checksum 0x1310, unused inodes 512
Backup superblock at 8193, Group descriptors at 8194-8217
Reserved GDT blocks at 8218-8473
Block bitmap at 283 (bg #0 + 282), Inode bitmap at 299 (bg #0 + 298)
Inode table at 442-569 (bg #0 + 441)
7911 free blocks, 512 free inodes, 0 directories, 512 unused inodes
Free blocks: 8193-16384
Free inodes: 513-1024
Notice how the "free blocks" range includes the backup sb & GDT area
and doesn't match the free block count.
Worse yet, debugfs' testb command will report those group descriptor
blocks as not being in use unless the user also instructs debugfs to
find a free block first. That is a rather surprising result:
debugfs: testb 8194
Block 8194 not in use
debugfs: ffb 1 16380
Free blocks found: 16380
debugfs: testb 8194
Block 8194 marked in use
Also, remove the part of check_block_uninit() that "fixes" the bitmap
since we're doing that at bitmap load time now.
[1] kernel git 717d50e4971b81b96c0199c91cdf0039a8cb181a
"Ext4: Uninitialized Block Groups"
[2] e2fsprogs git f5fa20078b
"Add support for EXT2_FEATURE_COMPAT_LAZY_BG"
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
On a filesystem with 1K blocks and meta_bg enabled, opening a
filesystem with automatic superblock detection tries to compensate for
the fact that the superblock lives in block 1. However, the method by
which this is done is later misinterpreted to mean "read the backup
group descriptors", which is not what we want in this case.
Therefore, in ext2fs_open3() separate the 'group zero' adjustment into
its own variable so that we don't get fed backup group descriptors
when we try to load meta_bg group descriptors.
Furthermore, enhance ext2fs_descriptor_block_loc2() to perform its own
group zero correction. The other caller of this function neglects to
do any group-zero correction of their own, so this fixes them too.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
If ext2fs_descriptor_block_loc2() is called with a meta_bg filesystem
and group_block is not the normal value, the function will return the
location of the backup group descriptor block in the next block group.
Unfortunately, it fails to account for the possibility that the backup
group contains a backup superblock but the regular superblock does
not. This is the case with block groups 48-49 on a meta_bg fs with 1k
blocks; in this case, libext2fs will fail to open the filesystem.
Therefore, teach the function to adjust for superblocks in the backup
group, if necessary.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Also remove redundant close() of state_fd, since the fclose() of
state_f will result in the fd being closed.
Addresses-Coverity-Id: #1049146
Addresses-Coverity-Id: #26092
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Now that subst is using config.h, we need to fix its dependencies so
that if config.h is missing (i.e., after a "make clean" in the tree)
that it is rebuilt by the Makefile rule.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The races would be hard to exploit, but let's close them off.
Addresses-Coverity-Id: #709504
Addresses-Coverity-Id: #709505
Addresses-Coverity-Id: #709506
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The dietlibc doesn't support the TZ environment variable, which is
required by the standard. Work around this so that we can run the
regression test suite when building with dietlibc. (This is useful
for finding problems.)
With this change, the only thing which doesn't work as far as dietlibc
is concerned is the posix_memalign test, and the MMP support tests
(because posix_memalign isn't provided by dietlibc, sigh.)
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Commit 191a03ac5f was an incorrect fix for this issue. Fix it up.
Addresses-Coverity-ID: #295143
Addresses-Coverity-ID: #1148451
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Now that the diet libc support is working again, we need to use the
internal uuid and blkid library in order for e2fsck.static to be
compiled properly.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Some different types such as u_int16_t and __uint32_t have snuck into
e2fsprogs. These types are not guaranteed by any standard, and they
are not provided by dietlibc. Convert them to __u16, __u32,
etc. since these are guaranteed to be provided by e2fsprogs' build.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Newer versions of autoconf pull in AC_PROG_GCC as part of
AC_CANONICAL_HOST. So we need check for WITH_DIET_LIBC earlier in
configure.in.
Also, e2fsprogs now needs functions which are found in diet libc's
compat library. So add support for autoconf's LIBS function, and
automatically set libs to include -lcompat.
Finally, disable compiling e4defrag by deault if --with-diet-libc is
specified because the program has too many glibc dependencies.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Use posix_fadvise64() when available. This allows 64bit offsets on
32bit systems.
[ Modified by tytso to try to use fadvise64() as well, and to remove
the attempt to call the syscall directly, since because and
complexities caused by required dummy arguments on some
architectures, it's not worth the hair. ]
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This happens if there is an error while scanning a directory for
config file fragments. This is rarely used, which is why we didn't
notice this.
Addresses-Coverity-Bug: #1138576
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The read_journal_block() function was needlessly complicated, which
made it harder to read/maintain, and it also tripped up Coverity.
Cleaning it up also avoided some signed/unsigned casts, and allows us
to avoid passing got back to the caller, since it wasn't needed.
Addresses-Coverity-Bug: #709539
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Add appropriate error checking for all error returns, and only open
each file that we need to manipulate once, to avoid potential
time-of-check/time-of-use races. (Not that this is likely for this
program, but the result is much more clean.)
We also preserve the atime in the case where the file has not changed.
Addresses-Coverty-Id: #709537
Addresses-Coverty-Id: #1049150
Addresses-Coverty-Id: #1049151
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
It's highly unlikely after five seconds that zero blocks would have
been written, but let's silence the Coverity warning.
Addresses-Coverity-ID: 1147780
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Dividing a floating point number by zero is undefined in C. It
happens to work with gcc/glibc, but it's not something that's
guaranteed.
Addresses-Coverity-ID: #1147781
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
