Use "[u]" instead of "[uninit]" and limit the amount of detail printed
for the extent tree blocks, so it is more similar to the format used
for direct/indirect mapped inodes.
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>
Mistakes on the commandline can lead to odd error messages:
# mke2fs -t ext4 -E stride=128 stripe-width=512 /dev/sda1
mke2fs: invalid blocks count - /dev/sda1
Making it a bit more explicit is more obvious:
mke2fs: invalid blocks count '/dev/sda1' on device 'stripe-width=512'
(hint, the mistake was no comma separation for -E)
Reported-by: Adam Huffman <bloch@verdurin.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
If a device supports discard -and- returns 0s for discarded blocks,
then we can skip the inode table initialization -and- the inode table
zeroing at mkfs time, and skip the lazy init as well since they are
already zeroed out.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
When a device name is misspelled, we output the full text about specifying
alternate superblock. This is slightly misleading because when the device
cannot be open because of ENOENT, this certainly won't help. So just print
that device does not exist and exit.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This bit of the mke2fs manpage is slightly confusing:
-b block-size
Specify the size of blocks in bytes. <snip>
If block-size is negative, then mke2fs will use heuristics
to determine the appropriate block size, with the constraint
that the block size will be at least block-size bytes.
because it sounds like the block size will be at least a negative
number. Clarify just what the negative sign means.
Reported-by: Chris Frost <chris@frostnet.net>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
These patches fix obvious bone-headed mistakes, so e2fsprogs will now
build and mostly work on powerpc. The m_meta_bg, u_mke2fs, and
u_tune2fs tests are still failing, however, so there's still work to do...
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This adds a 64-bit interface for ext2fs_file_size_size() and enhances
it to trunate the file if necessary.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This patch adds a very simple function:
struct ext2_inode *ext2fs_file_get_inode(ext2_file_t file);
which is useful for fuse-ext2 when it needs to read the inode of an
open file.
Signed-off-by: renzo davoli <renzo@cs.unibo.it>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Previously, ext2fs_extent_open2() copied the passed-in inode structure
into the extent handle, and the extent functions modified the copy of
the inode structure if necessary due to extent splits, etc. Change
ext2fs_extent_open2() so that the extent functions use the inode
structure passed into ext2fs_extent_open2(). Otherwise the passed-in
inode structure could become out of date due to changes made by the
extent functions.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Requiring an immediate pre-fsck before printing a minimum
resize size seems a bit draconian; if the fs isn't clean or marked
with error, then certainly, but for an informational minimum
size, I don't think we need to require a fsck since last mount.
I had simply copied the checks from the actual resize path,
previously.
Installers use this option (-P) to gather minimum resize info,
and requiring an actual fsck before use just seems to go too far.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Commit 641b66b fixed a floating point precision error which can result
in a search algorithm looping forever. It can also result in an array
index being out of bounds and causing a segfault. Here are two more
cases in e2fsck and resize2fs that need to be fixed. I've just used
the same fix from the that commit.
Signed-off-by: Lachlan McIlroy <lmcilroy@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
In the case where the original superblock and the backup superblock
are both invalid in some way, e2fsck will try to go back to the
orignal superblock. To do that, it must close the attempted open
using the backup superblock first (since otherwise the exclusive open
will prevent the subsequent open from succeding).
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The getopt() function returns an int, not a char. On systems where the
default char is unsigned (like ppc), we get weird behavior where -1 is
truncated to 0xff but compared to (int)-1.
Also fix this same bug for two test programs, test_rel and iscan,
which aren't currently used at the moment.
Addresses-Gentoo-Bug: #299386
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
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>
To prevent direct array indexing of fs->group_desc[i] (because the
group_desc may be a different size for different filesystems) make it
an opaque pointer that may only be accessed through the accessor
functions in blknum.c. The type itself is still available in a public
header; if we have a group_desc that we know is one type or another,
it's ok to access its fields directly. This change only prevents us
from indexing off fs->group_desc[i] directly.
Old-style applications who don't want to change their source code can
(as a temporary short-term hack) #define EXT2FS_OLD_32_COMPAT before
including ext2fs.h.
Change the accessors in blknum.c to use ext4fs_group_desc(), a version
of ext2fs_group_desc() which returns a ext4_group_desc pointer.
This simplifies and collapses a fair bit of code in blknum.c
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
We need to defer setting the blocks count field in the fs_param
structure until it is known whether 64-bit feature will be enabled
(and whether the blocks count is valid).
We also add a new mke2fs.conf configuration parameter,
auto_64-bit_support which will automatically enable the 64-bit feature
if the number of blocks requires it.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Use 64-bit interfaces in mke2fs. This should be most most of whats
needed to support creating a 64-bit filesystem.
Signed-off-by: Jose R. Santos <jrs@us.ibm.com>
Signed-off-by: Valerie Aurora Henson <vaurora@redhat.com>
Signed-off-by: Nick Dokos <nicholas.dokos@hp.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This is needed to enable 64-bit mke2fs to work correctly.
Signed-off-by: Jose R. Santos <jrs@us.ibm.com>
Signed-off-by: Valerie Aurora Henson <vaurora@redhat.com>
Signed-off-by: Nick Dokos <nicholas.dokos@hp.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Theodore Ts'o