linux-ext4 - Re: Question on block group allocation

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: <20090429215032.GC24749@mit.edu>
Date:	Wed, 29 Apr 2009 17:50:32 -0400
From:	Theodore Tso <tytso@....edu>
To:	Curt Wohlgemuth <curtw@...gle.com>
Cc:	Andreas Dilger <adilger@....com>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: Question on block group allocation

Oh --- one more question.  You did these tests on your 2.6.26-based
kernel with ext4 backports, right?  Not 2.6.30 mainline kernel?  Did
you backport the changes to the block and inode allocators?  i.e.,
this patch (plus a 1 or 2 subsequent bug fixes)?


commit a4912123b688e057084e6557cef8924f7ae5bbde
Author: Theodore Ts'o <tytso@....edu>
Date:   Thu Mar 12 12:18:34 2009 -0400

    ext4: New inode/block allocation algorithms for flex_bg filesystems
    
    The find_group_flex() inode allocator is now only used if the
    filesystem is mounted using the "oldalloc" mount option.  It is
    replaced with the original Orlov allocator that has been updated for
    flex_bg filesystems (it should behave the same way if flex_bg is
    disabled).  The inode allocator now functions by taking into account
    each flex_bg group, instead of each block group, when deciding whether
    or not it's time to allocate a new directory into a fresh flex_bg.
    
    The block allocator has also been changed so that the first block
    group in each flex_bg is preferred for use for storing directory
    blocks.  This keeps directory blocks close together, which is good for
    speeding up e2fsck since large directories are more likely to look
    like this:
    
    debugfs:  stat /home/tytso/Maildir/cur
    Inode: 1844562   Type: directory    Mode:  0700   Flags: 0x81000
    Generation: 1132745781    Version: 0x00000000:0000ad71
    User: 15806   Group: 15806   Size: 1060864
    File ACL: 0    Directory ACL: 0
    Links: 2   Blockcount: 2072
    Fragment:  Address: 0    Number: 0    Size: 0
     ctime: 0x499c0ff4:164961f4 -- Wed Feb 18 08:41:08 2009
     atime: 0x499c0ff4:00000000 -- Wed Feb 18 08:41:08 2009
     mtime: 0x49957f51:00000000 -- Fri Feb 13 09:10:25 2009
    crtime: 0x499c0f57:00d51440 -- Wed Feb 18 08:38:31 2009
    Size of extra inode fields: 28
    BLOCKS:
    (0):7348651, (1-258):7348654-7348911
    TOTAL: 259
    
    Signed-off-by: "Theodore Ts'o" <tytso@....edu>

						- 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