From: Theodore Ts'o <tytso@mit.edu>
To: Killian De Volder <killian.de.volder@scarlet.be>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Recovery after mkfs.ext4 on a ext4
Date: Sun, 22 Mar 2015 16:19:13 -0400 [thread overview]
Message-ID: <20150322201913.GA28505@thunk.org> (raw)
In-Reply-To: <550E7B05.7020703@scarlet.be>
On Sun, Mar 22, 2015 at 09:19:17AM +0100, Killian De Volder wrote:
> On 23-06-14 19:31, Theodore Ts'o wrote:
> >
> > ...
> > We do actually keep a linked list of these inode numbers so we can try
> > to report a directory name so you know which file has been trashed.
> > This happens in pass #2, so the inodes which are invalid are stored in
> > pass #1 and only removed in pass #2.
> >
> > So if you are seeing gazillions of bad inodes, that could very easily
> > be what's going on. If so, I can imagine having some mode that we
> > enter after a hundred inodes where we just ask permission to blow away
> > all of the corrupted inodes in pass #1, without waiting until we can
> > give you a proper pathname.
> > ...
> >
> >
> > - Ted
> >
> Been thinking, maybe I should rewrite this code to used linked-arrays ?
> Linked lists are painfully slow on swap. (and cpu too because of all the cache misses)
> Or are we doing a lot of inserts ?
I'm not sure why I said linked lists last June, but that's actually
not correct. In old versions of e2fsck, we used a bitmap to mark
which inodes were bad. In newer versions of e2fscks, we have an
alternative representation for bitmaps where we can used red/black
trees for extents (contiguous regions of blocks or inodes that are
"set" in the bitmap).
In any case, I don't think trying to further optimize how we store bad
inodes is really worth it. It happens extremely rarely, and it's
probably more useful to consider how we can avoid these sorts of
things from happening in the future.
For example, e2fsck and mke2fs will try to open the file system using
the O_EXCL flag. The kernel will not allow the file system to opened
if either (a) the file system is mounted, or (b) some other file
system has the block device opened using O_EXCL. From looking at the
e-mail thread history, the problem was that you accidentally ran
mke2fs on a file system that was mounted via qemu. So if qemu opens
its block devices with O_EXCL, that would avoid a lot of problems.
In addition, newer versions of mke2fs will now warn you when you try
running mke2fs on an existing file system:
mke2fs 1.42.12 (29-Aug-2014)
/dev/sda3 contains a ext4 file system labelled 'test-filesystem'
created on Sun Mar 22 16:18:03 2015
Proceed anyway? (y,n)
Cheers,
- Ted
prev parent reply other threads:[~2015-03-22 20:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-15 8:12 Recovery after mkfs.ext4 on a ext4 Killian De Volder
2014-06-15 13:20 ` Theodore Ts'o
2014-06-15 20:27 ` Killian De Volder
2014-06-15 21:44 ` Theodore Ts'o
2014-06-23 6:09 ` Killian De Volder
2014-06-23 12:37 ` Theodore Ts'o
2014-06-23 16:37 ` Killian De Volder
2014-06-23 17:31 ` Theodore Ts'o
2014-06-23 18:34 ` Killian De Volder
2015-03-22 8:19 ` Killian De Volder
2015-03-22 20:19 ` Theodore Ts'o [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150322201913.GA28505@thunk.org \
--to=tytso@mit.edu \
--cc=killian.de.volder@scarlet.be \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).