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

On Apr 22, 2008  08:46 -0400, Theodore Ts'o wrote:
> Change the way we allocate bitmaps and inode tables if the FLEX_BG
> feature is used at mke2fs time.  It places calculates a new offset for
> bitmaps and inode table base on the number of groups that the user
> wishes to pack together using the new "-G" option.  Creating a
> filesystem with 64 block groups in a flex group can be done by:
> 
> mke2fs -j -I 256 -O flex_bg -G 32 /dev/sdX

Presumably you mean "-G 64" based on your description of 64 groups/flex_bg?

> @@ -66,6 +137,22 @@ errcode_t ext2fs_allocate_group_table(ext2_filsys fs, dgrp_t group,
> +		if (flexbg_size) {
> +			dgrp_t gr = ext2fs_group_of_blk(fs, new_blk);
> +			fs->group_desc[gr].bg_free_blocks_count--;
> +			fs->super->s_free_blocks_count--;
> +			fs->group_desc[gr].bg_flags &= ~EXT2_BG_BLOCK_UNINIT;
> +			ext2fs_group_desc_csum_set(fs, gr);
> +		}

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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ