linux-ext4 - Re: [E2FSPROGS, RFC] mke2fs: 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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 25 Apr 2008 14:10:26 -0600
From:	Andreas Dilger <adilger@....com>
To:	"Jose R. Santos" <jrs@...ibm.com>
Cc:	"Theodore Ts'o" <tytso@....edu>, linux-ext4@...r.kernel.org,
	Valerie Clement <valerie.clement@...l.net>
Subject: Re: [E2FSPROGS, RFC] mke2fs: New bitmap and inode table allocation	for
 FLEX_BG

On Apr 23, 2008  16:05 -0500, Jose R. Santos wrote:
> On Wed, 23 Apr 2008 14:39:55 -0600
> Andreas Dilger <adilger@....com> wrote:
> > It makes total sense to me that the BG_BLOCK_UNINIT flag would not be set
> > on a group that does not have the default bitmap layouts, so I agree with
> > this change.  I might suggest that we add a new flag BG_BLOCK_EMPTY or
> > similar (which is really part of the FLEXBG feature so it doesn't affect
> > the existing uninit_groups code) that indicates that the block bitmap
> > contains NO allocated blocks, so that the kernel can know immediately
> > when reconstructing the bitmap that there are no bitmaps or itable in
> > that group (i.e. the bitmap is all zero).
> 
> I originally had a similar idea but was vetoed because there was no
> kernel user on the flag.  The flag that I used was set if the block
> group had meta-data as opposed to just being empty since there are still
> block groups out there that can have no meta-data but still have bgd or
> backup super blocks.  Would BG_BLOCK_EMPTY mean no bitmaps/inode tables
> or does it imply completely empty block group?

It could mean either...  What is important is if that is useful it should
be done before FLEXBG goes into the field.

The kernel can already determine somewhat efficiently whether a group
has sb or gdt backups, though it can't hurt to flag this also.  What
seems to be quite difficult is to know in the presence of FLEXBG whether
a group has an itable or bitmap in it.

I'd HOPE (and I believe this is what Ted's recent patch did) is that any
group which is being used to store flexbg data will have an initialized
block bitmap in it, because it is "non-standard".

What is more tricky is if a group has BLOCK_UNINIT and/or INODE_UNINIT
set what should happen when that group's block bitmap is initialized.
Should it assume there is a block + inode bitmap and an itable, or is
it enough to check its own group descriptor to determine if the bitmap
and itable are not in the group itself.

Maybe I'm being paranoid, and we don't need the flag(s), but better to
think the issues through now and decide we don't need them, than to
decide later that we do.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

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