The development branch of e2fsprogs already has a code point assigned
in conflict with EXT2_FLAG_DIRECT_IO. Fix this.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Allocate various memory structures to be properly aligned to avoid
needing to use a bounce buffer when doing direct I/O read/writes.
This should also help on FreeBSD systems which require aligned buffers
unconditionally.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This adds the basic support for Direct I/O to unix_io.c, and adds a
new flag EXT_FLAG_DIRECT_IO which can be passed to ext2fs_open() or
ext2fs_open2() to request Direct I/O support.
Note that device mapper devices in Linux don't support Direct I/O, and
in some circumstances using Direct I/O can actually make performance
*worse*!
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The test now checks to make sure the superblock fields are correctly
aligned and prints them out so they can be manually checked to make
sure they are where we expect them to be.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Add superblock fields which track where and when the first and most
recent file system errors occured. These fields are displayed by
dumpe2fs and cleared by e2fsck.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
We also support for byte-swapping the Next3 fields, although the
current Next3 implementation doesn't support big-endian systems.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reserve the EXT4_FEATURE_INCOMPAT_DIRDATA feature flag for adding
extra file data in ext2_dir_entry_2 entries.
This changes the on-disk layout in the following way.
Firstly, the ext2_dir_entry_2 file_type field now has a mask: that
limits the "filetype" information to the low 4 bits of this field.
Since these values are sequentially assigned, this allows for up to 7
more filetypes to be assigned. When reading the "filetype" field, the
high 4 bits should be masked off when converting to DT_* filetypes for
userspace.
The high 4 bits of "filetype" are used as a bitmask to register up to
4 different "extended" directory entry fields. Extended data fields
are packed without alignment into the directory entry after the "name"
field in order of increasing bitmask value, for each field where bit
is set. In order to avoid the need to "understand" each of the
extended fields, the first byte of each extended data field holds the
size of that data field (including the size itself), so they can be
skipped if not understood. For fields that change the semantics of
the filesystem it is expected that a separate ROCOMPAT or INCOMPAT
field is registered.
There is a single dirent data type defined currently, for Lustre:
which holds a 128-bit file identifier. It is expected that if there
are 64-bit inode values that this will be assigned the 0x20 value.
Should a need ever arise to use all 4 of the extended dirent data
fields, it would be possible to keep the last bit (0x80) for use as a
multiplexor that stores a 1-byte aggregate data size, then a series of
"<u8_size><u8_type><data>" records in the last extended data record.
It is not expected that this will actually be needed in the lifetime
of ext4.
Signed-off-by: Andreas Dilger <adilger@sun.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reserve the EXT4_INCOMPAT_EA_INODE feature flag for use with
large extended attributes that are stored in a separate inode.
This changes the on-disk format in several ways:
First, replace the e_value_block field with e_value_inum, so that
an xattr entry can reference an external inode. This field is
currently unused, as all of the entries live in the same block.
struct ext2_ext_attr_entry {
__u8 e_name_len; /* length of name */
__u8 e_name_index; /* attribute name index */
__le16 e_value_offs; /* offset in disk block of value */
> __le32 e_value_inum; /* inode in which the value is stored */
__le32 e_value_size; /* size of attribute value */
__le32 e_hash; /* hash value of name and value */
char e_name[0]; /* attribute name */
}
Second, add a flag to the inode that indicates it is using a large
(external) extended attribute. This is needed so that when unlinking
an inode the xattrs will be scanned to unlink the xattr inodes
referenced by the main inode.
Third, for inodes that have a number of xattrs that are larger than
a single block, but not large enough to justify an external inode
(less than 64kB total xattr size, due to e_value_offs limitation)
the ext2_ext_attr_header->h_blocks field can grow beyond a single
block to represent a contiguous allocation of blocks for the xattr.
Signed-off-by: Andreas Dilger <adilger@sun.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The system header file can end up causing type conflicts, and
including kernel header files is always dodgy/dangerous (and this case
not needed).
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Some devices, notably 4k sector drives, may have a 512 logical
sector size, mapped onto a 4k physical sector size.
When mke2fs is ratcheting down the blocksize for small filesystems,
or when a blocksize is specified on the commandline, we should not
willingly go below the physical sector size of the device.
When a blocksize is specified, we -must- not go below
the logical sector size of the device.
Add a new library function, ext2fs_get_device_phys_sectsize()
to get the physical sector size if possible, and adjust the
logic in mke2fs to enforce the above rules.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The top-level COPYING file states that the e2p and ext2fs libraries
are available under the LGPLv2. The files were incorrectly labelled.
Alex Thomas/Luster has been consulted wrt to the ext3_extents.h file;
the rest of the files were primarily authored by Theodore Ts'o.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
namei.o is also needed by e2initrd_helper.
Long term, if we care about reduced e2fsprogs builds, we need a more
general solution for deciding what .o files are needed for a
particular build. Given that install floppies are going (gone?) the
way the dodo bird, we probably don't care, though.
Addresses-Sourceforge-Bug: #2911433
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
When ext2fs_block_iterate2() is called on an extent-mapped file with a
depth > 1, it will erroneously calling the callback function starting
all over again with an offset of logical block 0. It shouldn't do
this, and it cases mke2fs to become very slow when creating files with
very large journals.
Fix this.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This is the userspace side of Jiaying's EOFBLOCKS patch. With
Aneesh's patches for .33, Jiaying's patch, and this one, xfstests
013/fsstress (even with direct IO enabled) has held up through many
runs.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
When trying to find the best place for the inode table in the last
flex block group, use the true size for the flex_bg's portion of the
inode table instead of the worst case required size of the inode table
fragment if the file system is resized. This fixes a corner case
where if the size of the filesystem is just big enough that there is
only room for a single block group in the last flex_bg, and that
partial block group is too small for the full portion of the inode
table, the inode table is placed in the very first block group:
Group 64: (Blocks 2097152-2099199) [INODE_UNINIT, ITABLE_ZEROED]
Checksum 0xd305, unused inodes 8080
Block bitmap at 2097152 (+0), Inode bitmap at 2097168 (+16)
Inode table at 8626-9130 (+4292878770)
^^^^^^^^^
Thanks to Vyacheslav Dubeyko for pointing this out.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Don't byte-swap the block number when setting i_block[x], since the
write_inode function will take of byte swapping the inode.
The phys_blk parameter contains an input parameter in the SET_BMAP
case, so it must be passed to ext2fs_bmap2() from the legacy function
ext2fs_bmap().
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Linux <= 2.6.19 contained a bug in the /proc/swaps code where the
header would not be displayed (the first line).
This issue has been reported by Mike Frysinger for swapon(8).
Signed-off-by: Karel Zak <kzak@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The f_illitable_flexbg test was failing on ppc, because
e2fsck_move_ext3_journal is doing a direct memcmp of i_block with
s_jnl_blocks, and failing.
This is because we don't swap extent data on read from disk; rather
we do it when we access the extents. However, ext2fs_swap_super
was swapping s_jnl_blocks unconditionally, so these didn't match.
Looks like we need to treat s_jnl_blocks the same as i_block, and
swap it on access, not on read. Except for the last i_size bit...
Reviewed-by: Andreas Dilger <adilger@sun.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
If the RO compat HUGE_FILE feature flag is set, but the inode's
HUGE_FILE_FL flag is not set, we should still pay attention to the
high 32 bits of the i_blocks filed.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Commit 1d9b818: dumpe2fs: Print more information about the inline journal
caused dumpe2fs to use ext2fs_file_open2(). Previously the file_io
functions were only used by debugfs, so if debugfs was disabled,
file_io was not built. Now that dumpe2fs is also using file_io, we
need to build it unconditionally.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The x86 BT assembly instructure can overshoot the end of a bit array
when testing a bit at the end of the bit array, even if it never needs
to look at those memory locations. This can cause a spurious
segmentation fault. If we allocate a little extra memory, it avoids
this problem. See:
http://faydoc.tripod.com/cpu/bt.htm
This doesn't happen on Linux, probably because of the glibc's malloc()
function works, but apparently it's a major problem on the *BSD
operating systems.
Addresses-Sourceforge-Bug: #2328708
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
For filesystms that have the extent feature enabled, we need to grab
the use EXT2_IOC_GETFLAGS so that we don't accidentally end up trying
to request clearing the EXT2_EXTENT_FL, which is not supported and
causes the tune2fs -j error out.
Also fix the error returning in ext2fs_add_journal_inode() so it
returns a proper error code if the fstat() or ioctl() calls fail.
Addresses-Launchpad-bug: #416648
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
We are using a signed int to store a block number in
ext2fs_allocate_group_table. We don't actually do any computation or
comparisons using it, so it shouldn't cause any bugs, but it's
technically incorrect, and it's possible an overly clever compiler
might do something wrong with it.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Avoiding inserting a new extent if it is possible to merge the new
block to the beginning or the end of the previous or next extent.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Comment out less common debugging printf's, and fix some type
warnings. Add high-level debugging printf's for ext2fs_extent_goto(),
ext2fs_extent_insert(), ext2fs_extent_delete(), ext2fs_extent_replace()
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Commit 0dc291611 introduced a regression when unmapping the first
block in an extent. This caused e2fsck -fD to corrupt large
directories if the directory has to shrink by more than one block.
The problem was set_bmap should only go to a next leaf when setting a
first block in an extent, and not when it is unmapping the first block
in an extent.
Addresses-Debian-Bug: #537510
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The tst_csum test is now part of csum.c, so there isn't a separate
tst_csum.c file that should be listed as one of the source files in
lib/ext2fs.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
In the case where we ext2fs_extent_set_bmap() is replacing the block
mapping at the beginning of an already-existing extent, insert a new
extent if necessary before shrinking an existing extent, to avoid data
loss if the disk is full.
This mostly addresses the problem described in Red Hat Bugzilla's
statistics are still wrong, but at least the files on the filesystem
are not corrupted. If there is a failure during the
inode_scan_and_fix pass, the simplest thing to do may be to tell the
user to run e2fsck -fy.
Addresses-Red-Hat-Bug: #510379
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Optimize ext2fs_test_block_bitmap_range() and add a new function,
ext2fs_test_inode_bitmap_range(), which works the same way as
ext2fs_block_bitmap_range() but for inode bitmaps. It's needed for
some code in the development branch, so let's drop it into the maint
branch to make life easier in the future.
Signed-off-by: Kazuya Mio <k-mio@sx.jp.nec.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Commit 53422e moved the new extent insertion in
ext2fs_extent_set_bmap() prior to the modification of the original
extent, but the insert function left the handle pointing to the new
extent. This left us modifying the -new- extent, instead of the
original one, and winding up with a corrupt extent tree something
like:
BLOCKS:
(0-1):588791-588792, (0):588791
We need to move back to the previous extent prior
to modification, if we inserted a new one.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Some people don't want to see the concise "kernel-style" make output.
This configure option allows build engines that want to see the full
set of commands executed by the makefile to get what they want. Most
people will find this more distracting than useful, unless they need
to debug the Makefiles.
(It is not necessary to rerun configure to enable this verbose make
output temprarily; if a developer wants to do a quick debug of a
directory's makefile, he or she can simply edit the definition of the
$(E) and $(Q) variables in the Makefile; instructions can be found in
the MCONFIG file which is included in at the beginning of every
Makefile.)
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The e2fsprogs makefiles were using the same Makefile variable
LIBCOM_ERR for the link-line arguments as well as the dependencies.
Since LIBCOM_ERR can now include non-file arguments such as
"-lpthread", we need to use a separate DEPLIBCOM_ERR variable that
only has build file dependencies.
Do the same thing for STATIC_LIBCOM_ERR and PROFILED_LIBCOM_ERR.
Addresses-Sourceforge-Patches: #2813809
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
ext2fs_validate_entry would read beyond the end of the block to get
dirent->rec_len for certain arguments (like if blocksize ==
final_offset). This patch adds a check so that doesn't happen, and
changes the types of the arguments to avoid a compiler warning.
Signed-off-by: Nic Case <number9652@yahoo.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Previously e2fsprogs interpreted 0 for a rec_len of 65536 (which could
occur if the directory block is completely empty in 64k blocksize
filesystems), while the kernel interpreted 65535 to mean 65536. The
kernel will accept both to mean 65536, and encodes 65535 to be 65536.
This commit changes e2fsprogs to match.
We add the encoding agreed upon for 128k and 256k filesystems, but we
don't enable support for these larger block sizes, since they haven't
been fully tested.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
I noticed that neither the journal nor resize inodes have
i_extra_isize set post-mkfs; while this isn't likely
to be a big problem, I think the below patch tidies
it up.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The ext2_extent_handle only has a struct ext2_inode allocated on
it, and the same amount copied into it in that same function,
but in update_path() we're possibly writing out more than that -
for example 256 bytes, from that address. This causes uninitialized
memory to get written to disk, overwriting the parts of the
inode past the osd2 member (the end of the smaller structure).
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Each time an extent handle is opened and closed, if the inode has an
extent tree which does not fit in the inode's i_block structure, a
filesystem block buffer was not getting released. Since e2fsck opens
an extent handle for every inode using extents, this can translate to
a very large amount of memory getting lost.
Thanks to Henrik 'Mauritz' Johnson for discovering and pointing out
this leak, which he ran into while running the "rdump" command in
debugfs.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Move the test code which is used to build the tst_csum progam from
tst_csum into csum.c under an #ifdef DEBUG to simplify things and to
avoid compile problems caused by not having a prototype for
ext2fs_group_desc_csum().
Addresses-Sourceforge-Bug: #2484331
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
To reduce user confusion, if the /etc/mtab file is missing
ext2fs_check_mount_point and ext2fs_check_if_mounted will return a
new, explicit error code to indicate this case.
Addresses-Debian-Bug: #527859
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The patch below adds a function, ext2fs_extent_open2(), that behaves
as ext2fs_extent_open(), but will use the user-supplied inode
structure when opening an extent instead of reading the inode from
disk. It also changes several of the calls to extent_open() to use
this enhancement.
Signed-off-by: Nic Case <number9652@yahoo.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>