Fix memory allocation calculations and check for NULL pointer returns.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Check the return values from ext2fs_get_block_bitmap_range2(); if an
error happened, print that and don't print garbage bitmap.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
sysconf(_SC_PAGESIZE) will probably never return an error, but just in
case it does, we shouldn't pass what looks like a huge number to
sync_file_range() and posix_fadvise().
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If someone umounts the filesystem between statfs64() and the getmntent()
iteration, we can exit the loop having never set mnt_type, and strcmp
can crash. Fix the potential NULL dereference.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
ext2fs_free_mem() takes a pointer to a pointer, similar to
ext2fs_get_mem(). Improve the documentation, and fix debugfs.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The caller of dump_file provides a fd to write to, so the caller
should also dispose of the fd. Also, the fd never gets closed if
preserve=1.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
When reading or writing file blocks, use the IO manager routines that
can handle 64bit block numbers.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
debugfs should use strtoull wrappers for reading block numbers from
the command line. "unsigned long" isn't wide enough to handle block
numbers on 32bit platforms.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If we have to create a big symlink (i.e. one that doesn't fit into
i_block[]), we are not 64bit block safe and the namei code does not
handle extents at all. Fix both.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
We should really use the ext2fs memory allocator functions in
copy_file(), and we really should return a value if there's allocation
problems.
Also fix up a minor bogosity in an error message.
Reviewed-by: Zheng Liu <wenqing.lz@taobao.com>
Cc: Robert Yang <liezhi.yang@windriver.com>
Cc: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Forbid clients from trying to map logical block numbers that are
larger than the lblk->pblk data structures are capable of handling.
While we're at it, don't let clients set the file size to a number
that's beyond what can be mapped.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The help text for debugfs' init_filesys command is incorrect; the
second parameter is the size of the filesystem in blocks, not the size
of an individual filesystem block. There is in fact no way to set
that parameter.
Reported-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
mke2fs has a series of checks to ensure that we don't create a
filesystem too big for its blocksize -- if auto-64bit is on, then it
turns on 64bit; otherwise it complains. Unfortunately, it performs
these checks before looking in mke2fs.conf for a blocksize, which
means that the checks are incorrect if the user specifies a non-4096
blocksize in the config file and says nothing on the command line.
The bug also has the effect of mandating a 4k block size on any block
device larger than 4T in that situation. Therefore, read the block
size from the config file before performing the 64bit checks.
Reviewed-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
For each site where we test for a large file (> 2GB) and set the
LARGE_FILE feature, use a helper function to make the size test
consistent with the test that's in e2fsck. This fixes the fsck
complaints when we try to create a 2GB journal (not so hard with 64k
block size) and fixes the incorrect test in fileio.c.
Reviewed-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
On a FS with a rather large blockize (> 4K), the old block map
structure can construct a fat enough "tree" (or whatever we call that
lopsided thing) that (at least in theory) one could create mappings
for logical blocks higher than 32 bits. In practice this doesn't
happen, but the 'max' and 'iter' variables that the punch helpers use
will overflow because the BLOCK_SIZE_BITS shifts are too large to fit
a 32-bit variable. The current variable declarations also cause punch
to fail on TIND-mapped blocks even if the file is < 16T. So enlarge
the fields to fit.
Yes, this is an obscure corner case, but it seems a little silly if we
can't punch a file's block 300,000,000 on a 64k-block filesystem.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Fix the e2fsck problem comments to match the actual message printed,
so that it is possible to find the problem code when searching by
the message.
Signed-off-by: Andreas Dilger <andreas.dilger@intel.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The ussage message for the open and filefrag commands were missing
options; this commit fixes this.
Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
commit 2ae5d1fdb8 was supposed to teach
'seti' and 'freei' to act on a range of consecutive inodes. apparently
only 'seti' has learned: 'freei' doesn't advance the ino, repeatedly
acting on the same one instead.
Signed-off-by: Lev Solomonov <solo@primarydata.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Fix the checking of s_mmp_block in e2fsck_pass1() and
ext2fs_mmp_read() to handle the high 32 bits of s_blocks_count.
Remove redundant check of s_mmp_block in do_dump_mmp() right before
ext2fs_mmp_read() is called.
Also fix s_blocks_count_hi in check_backup_super_block(), since it
cannot use the ext2fs_blocks_count() helper easily.
Signed-off-by: Andreas Dilger <adilger@dilger.ca>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The new resize tests create 2TB test files, but tmpfs in kernels
before 3.1 have a max file size of 256GB. Ext3 may also have
a size limit for smaller blocksize filesystems.
Fix the resize_test script to verify that $TMPFILE can be resized
to the final test size, and if that fails try creating the file on
the local filesystem instead of in $TMPDIR. If that cannot hold
the large filesystem, skip the test.
Signed-off-by: Andreas Dilger <adilger@dilger.ca>
Tested-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
A recent patch to fix blk_t to blk64_t assignment mismatches in
e2fsprogs (commit 4dbfd79d14) created
a printf conversion spec / argument type mismatch in tst_iscan.c.
Fix this to avoid truncation of the printed value and to silence
a compiler warning seen when "make check" is run.
Signed-off-by: Eric Whitney <enwlinux@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If we have a 64-bit file system with extended attribute blocks, e2fsck
would not correctly handle EA blocks that were located beyond the
32-bit block number boundary. Fix this by teaching
e2fsck/ea_refcount.c to use 64-bit block numbers.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If the external journal device has exactly 1 << 32 blocks,
journal->j_maxlen would get set to zero, which would cause e2fsck to
declare the journal to be invalid.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Use ext2fs_group_first_block2() instead of ext2fs_group_first_block()
to avoid dumpe2fs from printing crazy block offsets when we have block
numbers which are larger than 32 bits.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The resize inode only works on 32-bit block numbers, so use blk_t
instead of blk64_t. This avoids some -Wconversion noise, and slims
the compiled code slightly, especially on 32-bit platforms.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
We need to store some error codes using an int to keep recovery.c as
close as possible to the recovery.c source file in the kernel.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The use of ext2fs_write_dir_block() meant that attempts to fix
deleted/unused inodes in a directory would not be fixed for file
systems with 64-bit block numbers. (And some random block with the
high 32-bits cleared would get corrupted.)
Fix a similar problem when expanding directories and when creating the
lost+found dirctory.
Signed-off-by: Kit Westneat <kwestneat@ddn.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
These memory leaks were discovered by using "valgrind
--leak-check=full" while running "e2image -I bar.img foo.e2i"
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
e2image manually opens a new IO channel, and then sets the file system
to use this new IO channel via ext2fs_rewrite+to_io(). We need to
make sure the IO channel is set to the file system's block size to
avoid some nasty buffer overruns.
[ Modified by tytso to use io_channel_set_blksize() ]
Signed-off-by: Kit Westneat <kwestneat@ddn.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Commit bf0449b1a6, which added the ability to write qcow2 files,
generalized the write_header() file to take the size of the header
structure which it writes out. Unfortunately, it changed the call
which supported original e2image format to pass in fs->blocksize,
instead of the actual size of the e2image header structure (which is
substantially smaller than fs->blocksize). This meant that we copied
in stack garbage into the e2image file, and it made valgrind quite
unhappy.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Commit 832cb612: "e2fsprogs: add (optional) sparse checking to the
build" breaks systems that are not using GNU make. In addition, it
breaks if the developer tries to build in a subdirectory (i.e., if he
or she tries running "make" in the misc or e2fsck or lib/ext2fs
directory), since CHECK_CMD is not set.
Fix this by moving the sparse setup to MCONFIG.
Cc: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Don't accept block numbers larger than 2^32 for the badblocks list,
and don't run badblocks on them either.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Passing the "-E resize=NNN" option to mke2fs sets the resize_inode
feature. However, resize_inode and meta_bg are mutually exclusive;
unfortunately, we check this constraint before we parse the extended
options. Fix this by moving this check after the calls
parse_extended_opts().
Reported-by: "Darrick J. Wong" <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
When we've succesfully linked an inode into a directory, we can stop
iterating the directory.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
We need to build libquota even if the quota code is disabled. This
fixes a build regression introduced by commit 43075b42bd: 'quota: fix
disabling quota, add quota tests".
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The man page still said it was not possible to change the number of
inodes on a filesystem after creating it. You actually can by
resizing the fs, so clarify this language a bit.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Update all superblock copies when disabling the quota feature.
Added basic tests for the quota feature.
Signed-off-by: Niu Yawei <niu@whamcloud.com>
Signed-off-by: Andreas Dilger <adilger@whamcloud.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Darrick J. Wong