linux-ext4 - Re: 64bit filesystem questions

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]

Date:	Fri, 10 Jun 2011 13:45:20 -0400
From:	Phillip Susi <psusi@....rr.com>
To:	Andreas Dilger <adilger@...ger.ca>
CC:	linux-ext4@...r.kernel.org
Subject: Re: 64bit filesystem questions

On 6/10/2011 1:29 PM, Andreas Dilger wrote:
> On 2011-06-10, at 11:14 AM, Phillip Susi wrote:
>> On 6/10/2011 12:19 PM, Andreas Dilger wrote:
>>> I think in the presence of flex_bg this issue is moot.
>>
>> What is the issue without flex_bg?
>
> No "issue" really, just that the block/inode bitmaps are spread all over
> the filesystem.  The original discussion was about whether there could be
> "larger bitmaps that addressed more than 32768 blocks", which is essentially
> what the flex_bg feature provides.  With flex_bg the bitmaps for different
> groups will be allocated adjacent to each other on disk, and allow addressing
> more than 32768 blocks without any seeking.
>
> On large filesystems without flex_bg, the distribution of the bitmaps without
> flex_bg means that a seek is needed to read each one, and given that spinning
> disks have stayed at about 100 seeks/sec for decades it means 10+ minutes just
> to read all of the bitmaps.
>
> On my 2TB 5400 RPM SATA drive, e2fsck time went from ~20 minutes to ~3 minutes
> by copying the data to a new ext4 filesystem with flex_bg + extents.  For a
> fair comparison, I then reformatted the original (identical) disk without
> flex_bg or extents and copied the data back, so that there wasn't any unfair
> comparison between the newly-formatted filesystem and the old fragmented one.

I know what flex_bg is; what I don't understand is what it has to do 
with the limit on the size of a block group.  Whether the block bitmaps 
are stored in their native block group, or clustered up with flex_bg 
does not seem to have anything to do with whether or not the size of the 
bitmap can exceed 32k blocks.
--
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