linux-ext4 - Re: FAST paper on ffsck

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:	Thu, 30 Jan 2014 00:09:07 +0400
From:	Azat Khuzhin <a3at.mail@...il.com>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	"Darrick J. Wong" <darrick.wong@...cle.com>,
	"open list:EXT4 FILE SYSTEM" <linux-ext4@...r.kernel.org>
Subject: Re: FAST paper on ffsck

On Wed, Jan 29, 2014 at 11:40 PM, Theodore Ts'o <tytso@....edu> wrote:
> On Wed, Jan 29, 2014 at 11:21:07PM +0400, Azat Khuzhin wrote:
>>
>> Workload: there are _many_ files that don't deleted, append/full
>> rewrite/create only, lifetime 1-2 years:
>>
>>      8988871 inodes used (2.09%, out of 429817856)
>>      1012499 non-contiguous files (1.7%)
>>         2039 non-contiguous directories (0.0%)
>>              # of inodes with ind/dind/tind blocks: 0/0/0
>>              Extent depth histogram: 8616444/372389/30
>> # about 99% blocks in use wrong information, I shrinked fs before
>> this, to minimal size
>
>
> Shrinking the file system is known to result in really horrible
> fragmentation.  Part of this is because resize2fs has a really stupid
> block allocator, but if you're going to shrink the file system to
> minimal size the results can be truly catastrophic from a file
> fragmentation point of view.  (Imagine my horror when I was told that
> Fedora was creating bootable CD-ROM's by creating a large file system
> image, and then using resize2fs -M to shink it to minimal size.  Not
> only would the file layout be definitely non-optimal, but worse,
> CD-ROM drives are not know for fast seek times!)

Thanks, good to know.
Anyway, that fs already not used, it was once for migration,
and on new fs most of files already rewritten.

>
> We can probably make resize2fs smarter in the case where we are
> shrinking the file system slightly (say, to make room for LVM /thinp
> metadata when coverting a whole disk file system to one which is being
> managed via LVM).  But I'm not sure it's ever going to be worth it
> making resize2fs -M generate an optimal, minimally fragmented file
> system image.
>
>                                          - Ted



-- 
Respectfully
Azat Khuzhin
--
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