linux-ext4 - Re: [PATCH] e2fsprogs: New bitmap and inode table allocation for FLEX

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] [day] [month] [year] [list]

Date:	Mon, 11 Feb 2008 09:05:44 -0600
From:	"Jose R. Santos" <jrs@...ibm.com>
To:	Theodore Tso <tytso@....EDU>
Cc:	Andreas Dilger <adilger@....com>,
	linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] e2fsprogs: New bitmap and inode table allocation for
 FLEX_BG

On Sun, 10 Feb 2008 23:33:51 -0500
Theodore Tso <tytso@....EDU> wrote:

> On Fri, Feb 08, 2008 at 11:37:40AM -0600, Jose R. Santos wrote:
> > > >  #define EXT2_BG_INODE_UNINIT	0x0001 /* Inode table/bitmap not initialized */
> > > >  #define EXT2_BG_BLOCK_UNINIT	0x0002 /* Block bitmap not initialized */
> > > > +#define EXT2_BG_FLEX_METADATA	0x0004 /* FLEX_BG block group contains meta-data */
> > > 
> > > Hrm, I thought I had reserved that value in the uninit_groups patch?
> > > +#define EXT3_BG_INODE_ZEROED   0x0004  /* On-disk itable initialized to zero */
> > 
> > I may have been, I just based the patch on the next branch as Ted had
> > ask for new e2fsprog patches.  The uninit group patch was not part of
> > the next branch when I pulled.
> 
> Yes, but whenever you start reserving code points that impact the
> on-disk format, you need to be careful and coordinate.  Exactly is the
> purpose of this flag, and why is it here?

Will fix.

> And I don't see any patch in the kernel patch queue that uses this
> flag.  Is this intended for internal use inside e2fsprogs?  If so,
> this might not be the best place for it.....
> 
>      	       	      	   	     - Ted

Currently, this is only used in e2fsprogs to determine which groups to
avoid when setting the EXT2_BG_BLOCK_UNINIT.  It will be use on
ext4_init_block_bitmap() to return the right number of free block when
a block group does not have any meta-data in it.  Eventually, it would
be nice to accurately and efficiently calculate the number of meta data
block used for a flexbg and be able to have these block groups
uninitialized as well.  This flag will be use to determine which groups
need to have their meta data block usage calculated.

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