| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
A user received the "file system is mounted; do you really want to
continue" prompt, and then instead of typing "n" for no, forgot that
he hadn't declined to continuation question, and typed the up-arrow
key, which in his locale, the 'A' in "^[[A" was interpreted as "yes",
and he lost data.
This was clearly the user's fault, but to make e2fsck a bit safer
against user stupidity/carelessness, we will change the "fs is
mounted; continue?" prompt to default to no, and treat the escape
character (along with the return and space characters, currently) as a
request for the default answer.
Addresses-Debian-Bug: #619859
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>
|
|
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>
|
|
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>
|
|
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>
|
|
This prevents accidentally replaying and resetting the journal while
it is mounted, due to an accidental attempt to run e2fsck on an LVM
snapshot of a file system with an external journal.
Addresses-Debian-Bug: #587531
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>
|
|
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>
|
|
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>
|
|
This test, added to e2fsprogs-1.41.12, is backwards.
If EOFBLOCKS is set, then the size -should- be less than
the last physical block...
xfstests 013 caught this.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
|
|
It's a bad idea to set the checksums if e2fsck is aborted by the user,
and it often causes an error message, "Inode bitmap not loaded while
setting block group checksum info".
Addresses-Launchpad-Bug: #582035
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
These options allow e2fsprogs to be built using symlinks instead of
hard links, and to be installed using symlinks instead of hard links,
respectively.
Addresses-Sourceforge-Bug: #1436294
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
In the case where s_first_data_block is 1, we need to explictly reject
an extent whose starting physical block is zero.
Thanks to Jiaying Zhang <jiayingz@google.com> for finding this bug.
Addresses-Google-Bug: #2573806
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
If a corrupted file system causes us to want to delete an extent, and
that causes us to want to release a block in e2fsck pass #1, it would
be preferable if e2fsck didn't seg fault. This tends to get users
craky, as users are wont to do. :-)
Thanks to Dirk Reiners for reporting this bug:
e2fsck crashes fixing a corrupted 3.5 TB filesystem:
0x0000000000432002 in ext2fs_unmark_generic_bitmap (bitmap=0x0, bitno=623386749)
at gen_bitmap.c:183
183 if ((bitno < bitmap->start) || (bitno > bitmap->end)) {
(gdb) bt
bitno=623386749) at gen_bitmap.c:183
block=623386749) at ../../lib/ext2fs/bitops.h:319
inuse=-1) at alloc_stats.c:78
extent.c:1509
pb=0x7fffffffdfe0, start_block=0, ehandle=0x6dcf50) at pass1.c:1709
pb=0x7fffffffdfe0, start_block=0, ehandle=0x6dcf50) at pass1.c:1737
pctx=0x7fffffffe100, pb=0x7fffffffdfe0) at pass1.c:1842
block_buf=0x6c4330 "\373\212#") at pass1.c:1920
The source of the NULL bitmap is fs on stack frame 2:
(gdb) up 2
inuse=-1) at alloc_stats.c:78
78 ext2fs_unmark_block_bitmap(fs->block_map, blk);
Addresses-SourceForge-Bug: #2971800
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
There are broken embedded devices that have system clocks that always
reset to January 1, 1970 whenever they boot (even if no power is
lost). There are also systems that have super cheap clock crystals
that can be very inaccurate. So if the option broken_system_clock is
given, disable all time based checks. E2fsck will also try to detect
incorrect system clock times, and automatically mark the system clock
as insane.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
Justin reported that creating a 4T file with posix_fallocate led
to fsck errors:
e2fsck 1.41.10 (10-Feb-2009)
Pass 1: Checking inodes, blocks, and sizes
Inode 12, i_blocks is 8589935432, should be 840. Fix? yes
This looks like a 32-bit overflow.
commmit 8a8f36540bbf5d4397cf476e216e9a720b5c1d8e added handling of
the high i_blocks number, but we accumulate blocks in the num_blocks
field, and that's still just 32 bits.
Note: we don't need to expand max_blocks for now, that's only used
in the non-extents case, and those files have smaller max sizes.
I haven't been able to replicate the problem, oddly, but Justin
reports that this patch fixed his situation.
Reported-by: Justin Maggard <jmaggard10@gmail.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
|
|
For a filesystem that fails with:
journal_bmap: journal block not found at offset 7334 on loop0
JBD: bad block at offset 7334
e2fsck won't actually fix this; it will mark the fs as clean,
so it will mount, but it does not fix that block, and when the
journal reaches this point again it will fail again.
The following simple change to process_journal_block() might be
a little drastic; it will clear & recreate the journal inode if
it's sparse - i.e. if it gets block 0.
I suppose we could be more complicated and try to replay the journal
up to the error, but I'm not sure it's worth it since we're fscking
it anyway.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
|
|
There were a number of problems that were prompting the user whether
or not to ABORT, but then would abort regardless of whether the user
answered yes or no. Change those to be PROMPT_NONE, PR_FATAL.
Also, fix PR_1_RESIZE_INODE_CREATE so that it recovers appropriately
after failing to create the resize inode. This problem now uses
PROMPT_CONTINUE instead of PROMPT_ABORT, and if the user says, "no",
the code will abort.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
Commit 6267ee4 avoided repeating pass #1 over and over again if
multiple block groups are found with inodes in the bg_itable_unused
region during pass #2. This caused a regression because the problem
with not restarting pass #1 right away is that e2fsck will offer to
clear directory entries for inodes that are deleted, and e2fsck can't
easily distinguish between deleted inodes and inodes that were skipped
because of an incorrect bg_itable_unused value. So once an inode is
found in an unused region and we know that we're going to restart the
e2fsck pass, don't offer to clear any deleted inodes --- since those
will be caught in the second round.
Addresses-Google-Bug: #2642165
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
Some kernels will crash if EOFBLOCKS_FL is set when it is it not
needed, and this if it is left set when it isn't needed, it is a sign
of a kernel bug.
Addresses-Google-Bug: #2604224
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
blocks"
This reverts commit 0ea910997b3c2ba09b65b852b9bb4dd7b4d68999.
Since the Linux kernel now has support for the EXT4_EOFBLOCKS_FL flag
starting in 2.6.34, we don't need this workaround any more.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
If the user grows a partition bigger than 2**32 blocks, e2fsprogs
1.41.x is not going to be able to support resizing the filesystem,
since it doesn't have > 2**32 block support. However, e2fsck should
still work, so the system administrator doesn't get stuck.
Addresses-Launchpad-Bug: #521648
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
I guess the message wasn't scary enough for users who are just smart
enough to really get themselves in deep doo-doo. Let's make it even
scarier.
Addresses-Launchpad-Bug: #537483
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
A user was surprised when -n -D caused the file system to be opened
read/write, and then outsmarted himself when e2fsck asked the question:
WARNING!!! Running e2fsck on a mounted filesystem may cause
SEVERE filesystem damage.
Do you really want to continue (y/n)?
This is partially our fault for not documenting the fact that -D
overrode opening the filesystem read-write. But the bottom line is it
much safer if -n *always* opens the file system read-only, so there
can be no confusion. This means that we have to disable certain
combination of options, such as "-n -c", "-n -l", and "-n -L", and
"-n -D", but the utility of these combinations is pretty low, and
is more than offset by making e2fsck idiot-proof.
Addresses-Launchpad-Bug: #537483
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>
|
|
E2fsprogs 1.41.10 introduced a regression (in commit b71e018) where
e2fsck -fD can corrupt non-indexed directories when are exists one or
more file names which alphabetically sort before ".". This can happen
with ext2 filesystems or for small directories (take less than a
block) which contain filenames that begin with a space or some other
punctuation mark.
Fix this by making sure we never reorder the '.' or '..' entry in the
directory, since they must be first.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
Pass 1 has a test to see if a special file is really a directory.
Signed-off-by: Nick Dokos <nicholas.dokos@hp.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
The broken_system_clock allows the time to be in the future when in
preen mode. It's useful for people who have, as the name implies,
broken system clocks.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
The e2fsck_get_alloc_block() callback is used so that if the ext2fs
library needs to allocate blocks internally (most notably by the
extents functions), e2fsck's internal block usage map is consulted
since it is the only thing that can be trusted during a large part of
e2fsck's operation.
Change it to update the on-disk bitmap if it is loaded. This reduces
the number of spurious differences found in pass #5.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
In pass 2, when allocating new blocks for holes in directories, use
ext2fs_set_bmap() instead of ext2fs_block_iterate2() with a helper
function so that the newly allocated directory blocks are correctly
assigned in extent-mapped directories.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
Directories are not allowed to be sparse; the code for scanning
extent-mapped directories was not calling ext2fs_add_dir_block() for
missing directory blocks, so we weren't catching this form of file
system corruption. Fix this.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
The check that determines whether an directory needs to be have an
index added to it depends on i_size. So move it after we have fixed
up i_size so that we reliable will rehash a directory that needs it,
even if its i_size field was originally incorrect. Otherwise, a
second run of e2fsck would be needed before the directory gets an
index added.
Thanks to Mikulas Patocka for providing a sample file system which
demonstrated this problem.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
The old method for detecting directories with holes depended on i_size
being correct, even though the correct value of i_size hadn't been
calculated yet. Hence, a directory inode with holes and an i_size of
0 would require two e2fsck passes to fix completely.
The replacement method for determining whether or not
ext2fs_add_dir_block() should be called is more reliable, and reduces
the size of e2fsck and makes the code more readable as a bonus.
Thanks to Mikulas Patocka for providing a sample file system which
demonstrated this problem.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
Duplicate directory entries were not necessarily getting found and
fixed for non-indexed directories, since we were sorting these
directories by inode number, and the duplicate entry code assumed the
entries were getting sorted by name or directory name hash.
Addresses-Sourceforge-Bug: #2862551
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
Unfortunately, due to Windows' unfortunate design decision to
configure the hardware clock to tick localtime, instead of the more
proper and less error-prone UTC time, many users end up in the
situation where the system clock is incorrectly set at the time when
e2fsck is run.
Historically this was usually due to some distributions having buggy
init scripts and/or installers that didn't correctly detect this case
and take appropriate countermeasures. However, it's still possible,
despite the best efforts of init script and installer authors to not
be able to detect this misconfiguration, usually due to a buggy or
misconfigured virtualization manager or the installer not having
access to a network time server during the installation process. So
by default, we allow the superblock times to be fudged by up to 24
hours. This can be disabled by setting options.accept_time_fudge to
the boolean value of false in e2fsck.conf. The old
options.buggy_init_scripts is left for backwards compatibility.
Since we are now accepting the 24 hour time fudge by default, there is
no longer a need to install an Ubuntu-specific e2fsck.conf file, so we
can remove it.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
E2fsck was not properly printing the i_blocks field in filesystem
corruption messages, and it was not properly checking i_blocks_hi and
i_blocks_lo, either. This commit fixes this.
Thanks to Felipe Conteras for pointing this out.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
Non-expert users get confused when they see messages like this:
Illegal block #-1 (2291965952) in inode 176. CLEARED.
So change it to be something a little bit more understandable:
Illegal indirect block (2291965952) in inode 176. CLEARED.
Addresses-SourceForge-Bug: #2871782
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
This commit forces the use of the system-provided blkid or uuid header
files if we are using the system-provided blkid or uuid libraries.
This avoids using the in-tree header files with the system libraries.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
On a very low-memory system, where ext2fs_check_desc() fails because
it can't allocate a block bitmap, catch this error and report it
immediate. This avoids something like this, which could scare and
mislead the user:
e2fsck: Group descriptors look bad... trying backup blocks...
Media was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Error allocating block bitmap (1): Memory allocation failed
e2fsck: aborted
Addresses-Debian-Bug: #509529
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
Very often all the block group descriptors will have bad checksums, so
don't force the user answer 'yes' many, many times.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
If multiple blocks of a block group's inode table overlaps with other
file system blocks, only ask once for each block group.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
