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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 23 Jun 2014 18:37:20 +0200
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 14:37, Theodore Ts'o wrote:
> On Mon, Jun 23, 2014 at 08:09:37AM +0200, Killian De Volder wrote:
>> It's still checking due to the high amount of ram it's using.
>> However if I start a parallel check with -nf if find other errors the one with the high memory usage hasn't found yet ?
> No, definitely not that!  Running two e2fsck's in parallel will do far
> more harm than good.
In parallel is a big word: the check repair is SOOO slow, it might as well been killed when the second (read-only) test is done.
I once has a OOM because of tomuch ZRAM allocated, after I restarted e2fsck, it found more error before going into massive ram-usage.
So I was wonder what would happen if I restarted it.
>
>> Should I start a new one, or is this not advised ?
>> As sometimes I think it's bad inodes causing artificial usage of memory.
> What part of the e2fsck run are you in?  If you are in passes
> 1b/1c/1d, then one of the things you can do is to analyze the log
Pass 1: Checking inodes, blocks, and sizes
Notthing else below this except things like:

Too many illegal blocks in inode 488.
Clear inode<y>? yes

But no mention of any next pass.

This is the stack it's "stuck" on: (should compile one with debugging data)
#4  0x00007f1b0f1a0edb in block_iterate_dind ()
   from /lib64/libext2fs.so.2
#5  0x00007f1b0f1a1950 in ext2fs_block_iterate3 ()
   from /lib64/libext2fs.so.2
#6  0x00000000004118c3 in check_blocks ()
#7  0x0000000000412921 in process_inodes.part.6 ()
#8  0x0000000000413923 in e2fsck_pass1 ()
#9  0x000000000040e2cf in e2fsck_run ()
#10 0x000000000040a8e5 in main ()

So this is passA correct ?

> output to date, and individually investigate the inodes that were
> reported as bad using debugfs.  You could then backup what was worth
> backuping up out of those inodes, and then use the debugfs "clri"
> command to zap the bad inode.  I have done that to reduce the number
> of bad inodes to make e2fsck pass 1b, 1c, and 1d run faster.  But I've
> never done it on a really huge file system, and it may not be worth
> the effort.
>
> What I'd probably do instead is to edit e2fsck to skip pass 1b, 1c,
> and 1d, and then hope for the best.  The file system will still be
> corrupted, and there is the chance that you will do some damage in the
> later passes because you skipped passes 1b/c/d, but if the goal is to
> get the file system in a state where you can safely mount it
> read-only, that would probably be your best bet.
>
> 						- Ted
>
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