/boot/a: 0 extents found
works properly, but
Filesystem type is: ef53
Filesystem cylinder groups is approximately 61
File size of a is 0 (0 blocks, blocksize 1024)
ext logical physical expected length flags
a: 1 extent found
yields 1 extent when it should be 0.
Fix this up by special-casing no extents returned in verbose
mode; skip printing the header for the columns too, since there
are no columns to print.
Also, in nonverbose mode we can set fm_extent_count to 0
so that FIEMAP will just query the extent count without gathering
details; clarify this with a comment.
Addresses-RedHat-Bugzilla: 653234
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Fix a few typos in manpages.
Reported-by: Branislav Náter <bnater@redhat.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
It turns out that it's very hard to calculate overheads in the face of
clustered allocation (bigalloc). This is because multiple metadata
blocks from different block groups can end up in the same allocation
cluster. Calculating the exact overhead requires O(all block bitmaps)
in memory, or O(number of block groups**2) in time. So we will
calculate this at mkfs time and stash it in the superblock.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This adds the superblock fields needed so that dumpe2fs works and the
code points and renames the superblock fields from describing
fragments to clusters.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This patch adds support for detecting the new 'quota' feature in ext4.
The patch reserves code points for usr and group quota inodes and also
for the feature flag EXT4_FEATURE_RO_COMPAT_QUOTA.
Signed-off-by: Aditya Kali <adityakali@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
It is not true that 'nodiscard' is set as default, so remove this
sentence. The default is 'discard' and it is properly documented in man
page.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
User namespace xattrs are generally useful, and I think extN
is the only filesystem requiring a special mount option to
enable them, when xattrs are otherwise available. So this
change sets that mount option into the defaults, via a
mke2fs.conf option.
Note that if xattrs are config'd off, this will lead to a
mostly-harmless:
EXT4-fs (sdc1): (no)user_xattr options not supported
message at mount time...
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The forced fsck often comes at unexpected and inopportune moments,
and even enterprise customers are often caught by surprise when
this happens. Because a filesystem with an error condition will
be marked as requiring fsck anyway, I submit that the time-based
and mount-based checks are not particularly useful, and that
administrators can schedule fscks on their own time, or tune2fs
the enforced intervals if they so choose. This patch disables the
intervals by default, and I've added a new mkfs.conf option to
turn on the old behavior of random, unexpected, time-consuming
fscks at boot time. ;)
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
After debian bug #192277, debian/rules started making a symlink
to com_err.h in /usr/include. Now I have Fedora bug #550889
for the same issue, and perhaps it's time to make this link
by default, rather than fixing it up in packaging steps?
[ Changed by tytso to remove the explicit -s option; this will default
to creating a hard link by default, which slightly faster. If
people want to use symlinks for all links during the install
process, they can use configure option --enable-symlink-install.
The reason for this change is that some file systems, like AFS,
don't support symlinks, and AFS users complain when they can't build
or install into AFS. So I don't want to use symlinks
unconditionally without a way of switching things back and forth,
and it's easier if we just make all links made during the install
process to be hard links or sym links. ]
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
When using the -v option, report a breakdown of the number of read,
write, and comparison errors that were found by badblocks.
Thanks to Ragnar Kjørstad for providing this patch.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If there was a bad block for block #0, badblocks would never switch
back testing blocks more efficiently. In addition, we were
double-incrementing the blocks to be tested in the read/write test due
to failure to remove code.
Thanks to Ragnar Kjørstad for pointing these problems out.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
With Direct I/O, the kernel can report 0 bytes read even though the
first block has no errors. So there are any errors, we need try to
read/write blocks one at a time and to get an accurate report.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
I ran into odd behavior where mkfs.ext4 of a 16T filesystem would
create a resize inode with 0 reserved blocks, and mark the resize_inode
feature.
A subsequent slight downward resize of the filesystem would remove
the resize inode, making any further offline resizing impossible.
This is especially odd in light of the fact that a large downward
resize (say, to 8T) will actually add blocks to the resize inode -
so a small resize removes it, a large resize expands it ...
commit 8ade268cf2 had added this:
If the filesystem is grown to the point where the resize_inode is no
longer needed, clean it up properly so e2fsck doesn't have to.
but, it seems e2fsck does not care about this situation, either.
So, simply leave the resize_inode intact in this case, and everything
seems to be happy.
Note, this is for the 1.41.xx branch.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
If the file system has a blocksize less than 64k, then don't use the
extended rec_len encoding, to be consistent with what the kernel will
do.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Before we go whole-hog on 64-bit e2fsprogs, I wonder if this
is worth considering as a last-minute addition to the 1.41
stream. Currently, mke2fs will shave a block off an exactly-16T
device to fit*, but resize2fs does not do the same, leading
to some asymmetry. This patch fixes that up, and allows 16T
devices to be handled more gracefully in offline resize.
(in fact resize2fs will not even open a 16T device, today).
*commit 37d17a65ec
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Flags used during RHEL/Fedora builds lead to a couple type-punning
warnings:
recovery.c: In function 'do_one_pass':
recovery.c:539: warning: dereferencing type-punned pointer will break strict-aliasing rules
./csum.c: In function 'print_csum':
./csum.c:170: warning: dereferencing type-punned pointer will break strict-aliasing rules
The two changes below fix this up.
Note that the csum test binary output changes slightly, but this does
not break any tests.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
As recently discussed on linux-ext4@vger.kernel.org add an option to e2fsck
to allow to replay the journal only. That will allow scripts, such as
pacemakers 'Filesystem' RA to first replay the journal and if that sets
an error state from the journal replay, further check for that error
(dumpe2fh -h | grep "Filesystem state:") and if that shows and error
to refuse to mount. It also allows automatic e2fsck scripts to first
replay the journal and on a second run after the real pass1 to passX checks
to test for the return code.
Signed-off-by: Bernd Schubert <bschubert@ddn.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
If the user specifies "e2fsck -j UUID=XXX", e2fsck should do blkid
interpretation, since e2fsck does it with the base file system name.
So from the sake of consistency and user convenience, we should do it
here too.
Addresses-Debian-Bug: #559315
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The boolean options "force_no" in the problems stanza of e2fsck.conf
allows a particular problem code be treated as if the user will answer
"no" to the question of whether a particular problem should be fixed
--- even if e2fsck is run with the -y option.
As an example use case, suppose a distribution had widely deployed a
version of the kernel where under some circumstances, the EOFBLOCKS_FL
flag would be left set even though it should not be left set, and a
customer had a workload which exercised the fencepost error all the
time, resulting in many large number of inodes that had EOFBLOCKS_FL
set erroneously. Enough, in fact, the e2fsck runs were taking too
long. (There was such a bug in the kernel, which was fixed by commit
58590b06d in 2.6.36).
Leaving EOFBLOCKS_FL set when it should not be isn't a huge deal, and
is certainly than having high availability timeout alerts going off
left and right. So in this case, the best fix might be to put the
following in /etc/e2fsck.conf:
[problems]
0x010060 = { # PR_1_EOFBLOCKS_FL_SET
force_no = true
no_ok = true
no_nomsg = true
}
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
When running dumpe2fs on a filesystem formatted with flex_bg, it
prints out the relative offsets for the bitmaps and inode table
badly on 64-bit systems, because the offset is computed as a
large positive number instead of being a negative numer (which
will not be printed at all):
Group 1: (Blocks 0x8000-0xffff) [INODE_UNINIT, ITABLE_ZEROED]
Block bitmap at 0x0102 (+4294934786), Inode bitmap at 0x0202 (+4294935042)
Inode table at 0x037e-0x03fa (+4294935422)
This commit prints out the relative offsets for flex_bg
groups as the offset within the reported group. This makes it
more clear where the metadata is located, rather than simply
printing some large negative number.
Group 1: (Blocks 0x8000-0xffff) [INODE_UNINIT, ITABLE_ZEROED]
Block bitmap at 0x0102 (bg #0 +258), Inode bitmap at 0x0202 (bg #0 +514)
Inode table at 0x037e-0x03fa (bg #0 +894)
Signed-off-by: Andreas Dilger <adilger@dilger.ca>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If the user passes a file system type which is not defined in
mke2fs.conf (i.e., mke2fs -t xfs ...) change mke2fs so that it prints
a warning and aborts the run. (There is an exception for ext2, since
that file system does not need a special definition in the fs_types
section of the /etc/mke2fs.conf file.)
In addition, print a warning if there are usage types (specified using
the -T option) which are not defined in /etc/mke2fs.conf.
Addresses-Debian-Bug: #594609
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The dependency definitions for DEPSTATIC_LIBBLKID and
DEPPROFILED_LIBBLKID incorrectly referenced the non-dependency macros
(i.e., STATIC_LIBUUID instead of DEPSTATIC_LIBUUID). This resulted in
-luuid showing up as a Makefile dependency, which is of course wrong.
Addresses-Debian-Bug: #604629
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This fixes two possible causes for the error message:
WARNING: PROGRAMMING BUG IN E2FSCK!
OR SOME BONEHEAD (YOU) IS CHECKING A MOUNTED (LIVE) FILESYSTEM.
inode_link_info[X] is Y, inode.i_links_count is Z. They should be the same!
One cause which can trigger this message is when an inode has an
illegal link count > 65500 --- for example, 65535. This was the case
in the Debian Bug report #555456.
Another cause which could trigger this message is if an ext4 directory
previously had more than 65000 subdirectories (thus causing
i_link_count to be set to 1), but then some of the subdirectories were
deleted, such that i_link_count should now be the actual number of
subdirectories.
Addresses-Debian-Bug: #555456
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Clarify the e2fsck.conf(5) man page to make it clear that it applies
for ext4 file systems.
Addresses-Debian-Bug: #591083
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Carsten Hey