linux-ext4 - Re: Bug in delayed allocation: really bad block layouts!

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: <489FCFD4.2050602@redhat.com>
Date:	Mon, 11 Aug 2008 00:36:20 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	Theodore Tso <tytso@....edu>
CC:	linux-ext4@...r.kernel.org
Subject: Re: Bug in delayed allocation: really bad block layouts!

Theodore Tso wrote:
> 1;1613;0cOn Sun, Aug 10, 2008 at 03:04:00PM -0500, Eric Sandeen wrote:
>> # find . -name \*.h | xargs filefrag | grep -v extents | awk -F :
>> '{print $2}' | sort | uniq -c
>>    2460  1 extent found
>>
>> so *really* everything.
>>
> 
> Um, no, because you filtered out "extents", and filefrag will print "2
> extents found", so that it gets the singular/plural correct.

Oh, heh, whoops! :)  But still:

[root@...de test]# find . -name \*.h | xargs filefrag | grep -v "extents
format" | awk -F : '{print $2}' | sort | uniq -c
   2461  1 extent found

and to be sure:

[root@...de test]# find . -name \*.h | xargs filefrag | grep "extents
found"
[root@...de test]#

> One of
> the things I've been meaning to do is to clean up the output of
> filefrag so that it's a bit easier to parse.  It's really stupid for
> it to print "file is in extents format" over and over again...

I'm not really even sure why it should print it at all, ever, at least
without -vvv or something.  (That's what I meant to filter the first
time ;)  If the tool is to report layout I'm not sure the trivia about
how the layout is tracked internally is all that interesting.  The
fiemap patches for filefrag that print it out more as a table format,
more like xfs_bmap does, should be a lot better.  But anyway...

> I've done some research on my laptop's filesystem, and I've found
> examples of files with the characteristic horrendous layout going back
> as far back to at least July 7th.  (See below)
> 
> This takes us back to about the time when we were stablizing the
> patches that went into 2.6.26, and before the most recent set of
> patches to fix the journal credits and delayed allocation patches.
> 
> Interestingly, I'm not seeing the bad layouts for files created June
> 30th, which is when I switched my laptop's root filesystem to ext4.
> So that gives us a pretty good time bound on the patches that might be
> involved.  (This is a great demonstration of what it's a real win to
> manage the ext4 patch queue using git, since we can see which patches
> were added during that week or so.)
> 
> In other news, I've added an enhancement to e2fsck which makes it much
> easier to spot these sorts of problems.  On the latest e2fsprogs git
> branch, you'll be able to do "e2fsck -E fragcheck /dev/thunk/root" and
> get a report which makes it really ease to see the problem.
> 
> 						- Ted

Hm... I wonder why I'm not seeing it?

-Eric
--
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