linux-ext4 - Re: Fsck repair takes very long for 1,761 inodes containing multiply-claimed blocks on 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] [day] [month] [year] [list]

Date:	Sat, 18 Apr 2015 09:02:12 -0600
From:	Andreas Dilger <adilger@...ger.ca>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Akos Csete <akos.csete@...il.com>,
	"Darrick J. Wong" <darrick.wong@...cle.com>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: Fsck repair takes very long for 1,761 inodes containing multiply-claimed blocks on ext4

I had multiple-linked block problems this week as a CF card I was using in
a PVR started failing. The problem was just garbage in the inside table
that happened to have a bit of a pattern and caused many duplicate
blocks. 

One of the patches we have for Lustre, which unfortunately wasn't
installed on this system, is the ability to prefer erasing inodes with
duplicate blocks instead of cloning them. I think the last time I tried to
push this patch it got hung up because I don't understand how to
make the e2fsck.conf and command line defaults interact properly. 

http://git.hpdd.intel.com/tools/e2fsprogs.git/patch/1f9018d5ddf56d5feb9ef156c9684aee6d79cdee

The other patch that would be very useful in this case is "inode badness"
which tries to detect if inodes are garbage and just delete them instead
of turning them into something that appears good in small increments.

http://git.hpdd.intel.com/tools/e2fsprogs.git/patch/8528b0480b132dc9fae37a2e2efe5e9c24c3d56f

Ted didn't like the approach this patch had taken, because he thought
it touched e2fsck in too many places. I was thinking of a different way of
doing this, by hooking into fix_problem() if pctx->ino is set, but
I'm not yet sure if that will work. 

Cheers, Andreas

>> On Apr 17, 2015, at 15:08, Theodore Ts'o <tytso@....edu> wrote:
>> 
>> On Fri, Apr 17, 2015 at 04:05:04PM -0400, Akos Csete wrote:
>> 
>> Could I then just wipe the inodes of the older files (and restore them
>> later from backup) and let the new file claim those blocks? Or are the
>> new file's claim to those blocks suspect?
> 
> OK, if the mod times are different, then it probably wasn't a case of
> an inode getting written to the wrong place on disk.  What probably
> did happen is the block allocation bitmaps got corrupted, and so
> blocks that were in use (and should have been marked in use) were not,
> so they got used for some other inode.
> 
> So yes, you can try wiping the inodes for the older files, and hope
> for the best, but it may be that some of the newer files may end up
> getting corrupted.  So you might want to do some spot checks
> afterwards.  And if you have backups, this might be a good time to
> consider going to your backup tapes....
> 
>                        - 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
--
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