linux-ext4 - Re: e4defrag: Corrupt file after running e4defrag

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: <20170608223511.2dw7gyqzgwgxxz2q@thunk.org>
Date:   Thu, 8 Jun 2017 18:35:11 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     Marc Thomas <marc@...gonfly.plus.com>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: e4defrag: Corrupt file after running e4defrag

On Thu, Jun 08, 2017 at 03:12:27PM +0100, Marc Thomas wrote:
> Hello All,
> 
> After running "e4defrag" on an idle filesystem, I found a single file
> out of 893084 regular files had become corrupt (md5sum changed).
> I have repeated the process using an almost identical copy of the
> original filesystem, and a different single file became corrupt.

How big is the file system, and what file system features are enabled.
Can you send me a copy of "dumpe2fs -h" on the file system?  Something
else that would be useful would be to unmount the file system after
seeing the md5sum failure, and run e2fsck -fn to see if e2fsck noticed
any file system corruption.

I don't know if this will be doable, since it depends on how big the
file system is and how much extra space you have in your LVM volume
group, but what would be *wonderful* would be if you can do a full
image backup, or failing that, an compressed raw e2image backup (see
the e2image man page, or the "REPORTING BUGS" section of the e2fsck
man page).  The compressed raw e2image backup only contains the file
system metadata, and no the data blocks, so it takes much less space.

The idea then is after you discover which file is getting corrupted,
you can look that inode both on the "before" file system image
(looking only at the metadata blocks) and the "after" file system
image, and see if there are any clues about how to make a reproducible
test case, using the "stat" command of debugfs.  Getting a full
dumpe2fs output of the filesystem before and after might give us a
clue.

Thanks,

					- Ted