The public header files depend on the the autoconf defines
WORDS_BIGENDIAN and HAVE_SYS_TYPES_H, so we add them to ext2_types.h
so that external programs which try to use ext2fs_swap*() will work
correctly on big-endian systems. Fortunately, few if any programs
need to use this libext2's byte-swap functions directly.
Addresses-Debian-Bug: #484879
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This patch adds ZFS filesystem detection to libblkid.
It probes for VDEV_BOOT_MAGIC in the first 2 ZFS labels in big-endian
and little-endian formats.
Unfortunately the probe table doesn't support probing from the end of
the device, otherwise we could also probe in the 3rd and 4th labels (in
case the first 2 labels were accidentally overwritten)..
Eventually we would set the UUID from the ZFS pool GUID and the LABEL tag
from the pool name, but that requires parsing an XDR encoding of the pool
configuration which is not trivial.
Signed-off-by: Ricardo M. Correia <Ricardo.M.Correia@Sun.COM>
Signed-off-by: Andreas Dilger <adilger@sun.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The logical block numbers must be monotonically increasing, and there
must not be any overlapping extents. If any are found, report them as
filesystem corruption.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Wire up callback functions for ext2fs_alloc_block() and
ext2fs_block_alloc_stats() so that we use the ctx->block_found_map
block bitmap to determine which new block we should allocate, and then
to update the block_found_map bitmap if the extent functions need to
allocate or release blocks.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Add callback functions for ext2fs_alloc_block() and
ext2fs_block_alloc_stats(). This is needed so e2fsck can be informed
when the extent_set_bmap() function needs to allocate or deallocate
blocks.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This commit enables read/write access via the block iterator for
extent-based inodes.
Also fixed some bugs regarding the handling on non-leaf extent nodes
when iterating over extents in a file.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
ext2fs_extent_delete() will also update the parent node and decrement
the inode block count.
Passing in the EXT2_EXTENT_DELETE_KEEP_EMPTY flag will allow the empty
node to remain.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Allows unmapping or remapping single mapped logical blocks,
and mapping currently unmapped blocks.
Also implements ext2fs_extent_fix_parents() to fix parent
index logical starts, if the first index of a node changes
its logical start block.
Currently this can result in unnecessary new single-block extents; I
think perhaps ext2fs_extent_insert should grow a flag to request
merging with a nearby extent?
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
If ext2fs_extent_insert finds that the requested node
for insertion is full, it will currently fail.
With this patch it will split as necessary to make room, unless an
EXT2_EXTENT_INSERT_NOSPLIT flag is passed to it.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
When called for a given handle, the new function extent_node_split()
will split the current node such that half of the node's entries will
be moved to a new tree block. The parent will then be updated to
point to the (now smaller) original node as well as the new node.
If the root node is requested to be split, it will move all
entries out to a new node, and leave a single entry in the
root pointing to that new node.
If the reqested split node's parent is full it will recursively
split up to the root to make room for the new node's insertion.
If you ask to split a non-root node with only one entry,
it will refuse (we'd have an empty node otherwise).
It also updates the i_blocks count when a new block has
successfully been connected to the tree.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
If the inode's i_block[] array is completely empty, create an empty
extent tree in the in-core inode and set the EXT4_EXTENT_FL inode
flag. This makes it easy to create a new inode using extents.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
ext2fs_extent_delete() will leave the extent handle pointing at the
next extent --- except if the last extent in the node. To deal with
this last case, call ext2fs_get_extent_info() and stop scanning after
processing info->num_entries extents.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
ext2fs_delete_extent() deletes the current extent and moves to the
next extent (if present). So we need to skip moving to the next
extent and get the (new) current extent and check it before moving on.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Since version 2.50 autoconf fully supports checking sizes of types
(with AC_CHECK_SIZEOF) when cross-compiling. Therefore there is no
need to preset the respective cache variables anymore. The following
patch removes the special case. There is no need to adjust AC_PREREQ
as it's set to 2.50 already.
Tested successfully cross-building for the mips64el-linux-gnu host on
an i386-linux-gnu build system, removing the following warning
(because of a mismatch for the "long" type):
Sizeof(__U64__TYPEDEF) is 4 should be 8
Problem detected with asm_types.h
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This fixes problems turned up by a test case written by Erez Zadok's
group which constantly reformats filesystems.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
While synchronizing e2fsck's recovery.c with the latest 2.6 kernel
sources, I discovered a serious bug that apparently had been fixed in
the kernel sometime between Deceber 2003 and April 2005, but which had
not been carried over to e2fsprogs. Specifically, when blocks whose
first 4 bytes are JFS_MAGIC_NUMBER (0xc03b3998) are written into the
journal, the first 4 bytes zero'ed out. A one character typo meant
that when the blocks were replayed by e2fsck, the JFS_MAGIC_NUMBER
would not be restored.
Oops.
Fortunately, it is *highly* unlikely that ext4 metadata blocks will
contain that magic number in the first four bytes, and data=journalled
is a relatively rarely used.
This commit fixes this bug, as well as updating e2fsck's recovery.c to
be in sync with 2.6.25.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Theodore Ts'o