linux-ext4 - Re: Ext4 devel interlock meeting minutes (May 7, 2007)

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:	Wed, 09 May 2007 11:10:32 -0700
From:	Mingming Cao <cmm@...ibm.com>
To:	Andreas Dilger <adilger@...sterfs.com>
Cc:	Avantika Mathur <mathur@...ux.vnet.ibm.com>,
	linux-ext4@...r.kernel.org
Subject: Re: Ext4 devel interlock meeting minutes (May 7, 2007)

On Wed, 2007-05-09 at 10:37 -0700, Andreas Dilger wrote:
> On May 09, 2007  10:02 -0700, Avantika Mathur wrote:
> > Metablock Groups:
> > 
> > - Mingming mentioned that in the metablock group feature, the inode 
> > metadata is not moved with the rest of the metadata.  Ted will check 
> > this, as he thought this had been implemented.
> > 
> > - Online resize does not use metablock groups, and is currently limited 
> > to 2TB.
> > 
> > - Also need to remove sanity checks in the mount code
> > 
> > - Once these issues are fixed, the metablock group feature can be turned 
> > on by default for ext4 filesysytems
> 
> In my recent investigation of META_BG, it appears that BOTH the kernel
> and e2fsprogs do NOT handle group metadata (bitmaps, itable) outside the
> group.
> 
> In the kernel ext[234]_check_descriptors() requires the bitmaps and itable
> to be inside the group even though META_BG is supported for a long time.
> 
> In e2fsck/super.c check_super_block() also requires that the bitmaps and
> itable be inside the group even though e2fsck has claimed META_BG for a
> long time.
> 
> That means it is virtually impossible to allow the group metadata to move
> under the META_BG feature.

Understand it's not straightforward to turn on this feature by default.
Just try to understand, why the kernel and e2fsprogs issues you
mentioned above are not possible to fix to support full META_BG
feature? 

>   It might be possible to predicate this change
> under both 64BIT and META_BG, though this is somewhat non-standard.
> 
> Alternately, we could allow the relocation of bitmaps and itables under
> BIG_BG, which is itself covers the relocation aspects and also allows
> the ability to change the group size.
> 

Well, I think the previous discussion about BIG_BG feature leads us to
believe that turn on META_BG feature is good enough to support larger fs
and reduce fragmentation(which is the new BIG_BG feature is trying to
address).  After all the relocation of metadata (bitmaps, itables and
group descriptors) is what META_BG feature means.


Regards,
Mingming

-
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