mke2fs: add support for hugefiles_align

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
debian: fix dpkg-buildpackage for Debian Squeeze

Commit becb01ce84d breaks building e2fsprogs with dpkg 1.15.8 which is
used in Debian 6.0 (Squeeze), since it doesn't support package
specifications qualified with an architecture (i.e., "dpkg-query -W
libblkid1:amd64").

Debian only needs to use its own version of libblkid and libuuid for
versions of Debian 5.0 (Lenny) or before.  So default to using
util-linux-ng, instead of trying to test the version number of
libblkid1.

Lenny was released in February, 2009, and the current stable Debian
release is 7.x, so it is two stable releases back as of February 2014.
In the unlikely case someone needs to build a modern version of
e2fsprogs on a version of Debian which is five years old or older, can
create the file Debian/rules.custom with the line:

UTIL_LINUX_NG = no

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
debian: update debian/changelog and e2fslibs.symbols for 1.42.9-3 release

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Merge branch 'maint' into next

Conflicts:
	debian/changelog
	debian/e2fslibs.symbols
	version.h
configure: support biarch builds with --multiarch=lib64

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
mke2fs: minor bugfixes for mk_hugefiles

Interpret "zero_hugefiles" relation in mke2fs.conf as a boolean value,
as documented in the man page.

If the hugefile is larger than 2GB, set the large_file file system
feature so e2fsck doesn't complain.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
debian: add make variable to prevent building udeb packages

Setting SKIP_UDEBS=yes in rules.custom will prevent the debian/rules
makefile from building the udeb files for the debian installer.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
debian: fix spelling typo in debian/control.in

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
e2fsprogs: Disallow tune2fs enabling sparse_super with ext4 meta_bg enabled

When meta_bg feature is enabled, group descriptor block is allocated
every 128 block group (or every 64 block group if 64bit feature is
enabled).

In such situation, files in block group more than #128 will be removed
if sparse_super feature is enabled with tune2fs and afterwards
necessary e2fsck running.

Because tune2fs does not reallocate group descriptor blocks but just
set sparse_super feature.  If ext4 has sparse_super,
ext2fs_descriptor_block_loc2() called by e2fsck thinks the block group
(e.g. #128) that it has group descriptor block at the head offset. But
that offset is used as backup super block before.  So e2fsck fixes
ext4 based on invalid group descriptor blocks and this cause data
lost.

The patch avoids this problem simply by disallow tune2fs enabling
sparse_super if meta_bg is enabled.

Steps to reproduce:

1. Create ext4 which has meta_bg, ^sparse_super and 129+ block groups.
	# mke2fs -t ext4 -O meta_bg,^resize_inode,^sparse_super DEV 17G
	# mount DEV /MP

2. Create direcotry and files which use block group #128's metadata.
	# echo $((8192*128+1)) > /sys/fs/ext4/DEV/inode_goal
	# mkdir /MP/DIR
	# for i in $(seq 1 100); do dd if=/dev/urandom of=/MP/DIR/file$i bs=1024 count=10; done

3. Enable sparse_super with tune2fs then execute e2fsck.
   Data in block group #128 will be lost!!
	# umount DEV
	# tune2fs -O sparse_super DEV
	# e2fsck/e2fsck -yf DEV

Signed-off-by: Akira Fujita <a-fujita@rs.jp.ne.cocm>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
mke2fs: clean up kernel version tests

Refactor the running kernel version checks to hide the details of
version code checking, etc.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
libext2fs: iterate past lower extents during punch

When we're iterating extents during a punch operation, the loop exits
if the punch region is entirely to the right of the extent we're
looking at.  This can happen if the punch region starts in the middle
of a hole and covers mapped extents.  When this happens, we want to
skip to the next extent, because it might be punchable.

Also, if we've totally passed the punch range, stop.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
libext2fs: during punch, fix parent extents after modifying extent

When modifying/removing an extent during punch, don't forget to update
the extent's parents.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
libext2fs: don't hang on to unmapped block if extent tree update fails

If we're doing a BMAP_ALLOC allocation and the extent tree update
fails, there's no point in hanging on to the newly allocated block.
So, free it to make fsck happy.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
libext2fs: try to roll back when splitting an extent fails

If a client asks us to remap a block in the middle of an extent, we
potentially have to allocate a fair number of blocks to handle extent
tree splits.  A failure in either of the ext2fs_extent_insert calls
leaves us with an extent tree that no longer maps the logical block in
question and everything that came after it!  Therefore, try to roll
back the extent tree changes before returning an error code.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Merge branch 'maint' into next