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]

Message-Id: <7CFF213A-00F5-4E6B-A31C-F17FAA2FFB04@dilger.ca>
Date:	Fri, 10 Jun 2011 10:19:05 -0600
From:	Andreas Dilger <adilger@...ger.ca>
To:	Phillip Susi <psusi@....rr.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: 64bit filesystem questions

On 2011-06-10, at 9:19 AM, Phillip Susi wrote:
> On 6/9/2011 8:08 PM, Andreas Dilger wrote:
>> There is only a single block pointer for each bitmap per group.  That said,
>> with flex_bg this is mostly meaningless, since the bitmaps do not have to
>> be located in the group, and a flex group is the same as a virtual group
>> that is {flex_bg_factor} times as large.
> 
> Of course there is only a single pointer because there is only a single bitmap.  What does this have to do with limiting the block count to 8 * blocksize?

I think in the presence of flex_bg this issue is moot.

>>> 3)  Why does 64bit disable the resize inode?
>> 
>> Because the on-disk format of the resize inode is only suitable for 32-bit
>> filesystems (it is an indirect-block mapped file and cannot reserve blocks
>> beyond 2^32).  The "future" way to resize filesystems is using the META_BG
>> feature, but the ability to use it has not been integrated into the kernel
>> or e2fsprogs yet.
> 
> Ahh, right... no indirect blocks.  Couldn't and shouldn't the resize inode just use extents instead?  Also I thought that META_BG was an idea that eventually become FLEX_BG and has been dropped?

META_BG also reduces the number of group descriptor blocks needed for the table.

Normally (without META_BG) each group descriptor table has a full copy of all
group descriptor blocks, and it has to be allocated contiguously on disk.
With META_BG, there are only 2 backups of each GDT block, and it is spread
around the filesystem, so there is not a need to allocate huge chunks of space.

Once we get a filesystem up to 256TB in size the size of the GDT will be larger
than a whole group (more than 128MB per GDT) and it will not be possible to
create a larger filesystem without META_BG.


Cheers, Andreas





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