tests: add another test for uninit extents past eof

Commit d3f32c2db8 was intended to detect extents found outside their
proper location in the extent tree, including invalid extents at the
end of an extent block.  However, it incorrectly reported legal
uninitialized extents created by fallocate() at the end of file with
the FALLOC_FL_KEEP_SIZE flag as false positives.  xfstests
generic/263 (among others) caught this problem, while the e2fsprogs
test f_uninit_ext_past_eof did not.  The latter test failed to
detect the problem in part because it uses a test file whose i_size
is 0.

Add a test derived from the fsx-based test case in xfstests
generic/263 consisting of a file with non-zero length, more than
four extents total, and two uninitialized extents past EOF to
reliably reproduce commit d3f32c2db8's false positive behavior.

Signed-off-by: Eric Whitney <enwlinux@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
resize2fs: add debugging support for resize2fs -M calcuations

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
resize2fs: fix -M size calculations to avoid cutting off the inode table

If the file system's inode table blocks in the last block group are
located in the middle or the end of the block group, it's possible for
resize2fs -M to use a size which will require relocating the inode
table blocks in the last block group.  This can lead to all sorts of
problems, so solve it by simply guaranteeing that we will never do
that.

Reported-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
resize2fs: relocate inode table blocks if necessary when shrinking

If the file system is being shrunk, and a block group's inode table
falls beyond the end of the inode table, we need to try to relocate
the inode table blocks.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
tests: add test for resize2fs -M with inode table in middle of block group

Eric Sandeen reported that Fedora's mke2fs when compiled for ppc was
creating a file system which caused problems with resize2fs -M.
Closer examination showed that the problem was file system which
looked like this:

Filesystem features:      ext_attr dir_index filetype sparse_super
Inode count:              512
Block count:              1247
   ...

Group 0: (Blocks 1-1024)
  Primary superblock at 1, Group descriptors at 2-2
  Block bitmap at 66 (+65), Inode bitmap at 67 (+66)
  Inode table at 68-99 (+67)

Group 1: (Blocks 1025-1246)
  Backup superblock at 1025, Group descriptors at 1026-1026
  Block bitmap at 1090 (+65), Inode bitmap at 1091 (+66)
  Inode table at 1092-1123 (+67)

It's not obvious to me why Fedora's ppc mke2fs is creating file
systems like this (I can't reproduce this on debian ppc systems), but
resize2fs -M should be able to deal with such file systems, which is
what this test is designed to check.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
libext2fs: only link an inode into a directory once

The ext2fs_link helper function link_proc does not check the value of
ls->done, which means that if the function finds multiple empty spaces
that will fit the new directory entry, it will create a directory
entry in each of the spaces.  Instead of doing that, check the done
value and don't do anything more if we've already added the directory
entry.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
libext2fs: set the large_file feature flag when setting i_size > 2GB

If someone tries to write a file that is larger than 2GB, we need to
set the large_file feature flag to affirm that i_size_hi can hold
meaningful contents.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
libext2fs: fix a minor grammatical error in the error catalog

'an block' should be 'a block'.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
libext2fs: rewind extent pointer when totally deleting an extent

During a punch operation, if we decide to delete an extent out of the
extent tree, the subsequent extents are moved on top of the current
extent (that is to say, they're memmmove'd down one slot).  Therefore
it is not correct to advance to the next leaf because that means we
miss half the extents in the range!  Rereading the current pointer
should be fine.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
libext2fs: allow callers to punch a single block

The range of blocks to punch is treated as an inclusive range on both
ends, i.e. if start=1 and end=2, both blocks 1 and 2 are punched out.
Thus, start == end means that the caller wishes to punch a single
block.  Remove the check that prevents us from punching a single
block.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
libext2fs: ind_punch() must not stop examining blocks prematurely

When we're iterating the main loop in ind_punch(), "offset" tracks how
far we've progressed into the block map, "start" tells us where to
start punching, and "count" tells us how many blocks we are to punch
after "start".  Therefore, we would like to break out of the loop once
the "offset" that we're looking at has progressed past the end of the
punch range.  Unfortunately, if start !=0, the if-break clause in the
loop causes us to break out of the loop early.

Therefore, change the breakout test to terminate the loop at the
correct time.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
e2fsprogs: fix blk_t <- blk64_t assignment mismatches

Fix all the places where we should be using a blk64_t instead of a
blk_t.  These fixes are more severe because 64bit values could be
truncated silently.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
e2fsprogs: fix inode and block relocation functions to use blk64_t

The inode and block relocation functions aren't currently compiled in
(so we don't need to worry about breaking ABI compatibility).  They
were originally intended for use by resize2fs, but we never ended up
using them, so (wisely) they weren't ever included in libext2fs as an
exported interface (they're not even compiled by the Makefile).

Fix them so that in case we ever use them, so that in places where raw
data types (int, long, etc.) stood in for blk_t and blk64_t.  Also fix
some sites where we should probably be using blk64_t.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
libext2fs: update i_size in ext2fs_file_write()

ext2fs_file_write() needs to update i_size on successful write,
otherwise, ext2fs_file_read() in same open/close cycle will not
be able to read the just written data.

This fixes a bug which results in the the problem of quotacheck
triggered on 'tune2fs -O quota' failed to write back multiple
users/groups accounting information.

Signed-off-by: Niu Yawei <yawei.niu@intel.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
libext2fs: fix off-by-one error in file truncation

When told to truncate a file, ext2fs_file_set_size2() should start with
the first block past the end of the file.  The current calculation
jumps one more block ahead, with the result that it fails to hack off
the last block.  Adding blocksize-1 and dividing is sufficient to find
the last block.

Reviewed-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
libext2fs: search all possible blocks in implied_cluster_alloc()

implied_cluster_alloc() is written such that if the the user passes in
a logical block that is the zeroth block in a logical cluster (lblk %
cluster_ratio == 0), then it will assume that there is no physical
cluster mapped to any other part of the logical cluster.

This is not true if we happen to be allocating logical blocks in
reverse order.  Therefore, search the whole cluster, except for the
lblk that we passed in.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
mke2fs: complain about creating 64bit filesystems without extents

A 64bit filesystem without extents is not terribly useful, because the
old block map format does not support pointing to high block numbers.
Warn the user who tries to create such an animal.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
e2fsck: enable extents on all 64bit filesystems

Since it's impossible to address all blocks of a 64bit filesystem
without extents, have e2fsck turn on the feature if it finds (64bit &&
!extents).

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
libext2fs: openfs() musn't allow bigalloc without EXT2_FLAGS_64BITS

Currently, only the new 64-bit bitmap implementation supports the
block<->cluster conversions that bigalloc requires.  Therefore, if we
have a bigalloc filesystem, require EXT2_FLAGS_64BITS be passed in to
ext2fs_open().  This does not mean that bigalloc file systems have to
be 64-bits; just that the userspace utilities have to be able to use
the new 64-bit capable library functions.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
e2image: complain if running e2image -r or -Q on a mounted filesystem

Several users have used e2image on a mounted RW filesystem, resulting in
inconsistent, useless e2images for debugging purposes.

This commit will forbid this and print an error message, although the
user can override this using a new force option.

Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>