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] [thread-next>] [day] [month] [year] [list]

Message-ID: <550E7B05.7020703@scarlet.be>
Date:	Sun, 22 Mar 2015 09:19:17 +0100
From:	Killian De Volder <killian.de.volder@...rlet.be>
To:	Theodore Ts'o <tytso@....edu>
CC:	linux-ext4@...r.kernel.org
Subject: Re: Recovery after mkfs.ext4 on a ext4

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 ?

Think it might be worth it ? Would take me a week to learn the code in e2fsck though...
Biggest fear I have is making a mistake in the code that causes silent bugs.

Kind regards, Killian
--
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