linux-ext4 - Re: Recovery after mkfs.ext4 on a ext4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20150322201913.GA28505@thunk.org>
Date:	Sun, 22 Mar 2015 16:19:13 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Killian De Volder <killian.de.volder@...rlet.be>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: Recovery after mkfs.ext4 on a ext4

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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html