Re: Initial results of FLEX_BG feature.
On Jul 12, 2007 10:09 -0500, Jose R. Santos wrote:
@@ -1271,6 +1271,9 @@ static int ext4_check_descriptors (struc
ext4_debug (Checking group descriptors);
+ if (EXT4_HAS_INCOMPAT_FEATURE(sb, EXT4_FEATURE_INCOMPAT_FLEX_BG))
+ return 1;
+
for (i = 0; i sbi-s_groups_count; i++)
{
if (i == sbi-s_groups_count - 1)
It looks pretty straight forward to just change this code to leave
first_block at s_first_data_block, and leave last_block at ext4_blocks_count()
if FLEX_BG is set.
Even with FLEX_BG we want to keep the group metadata within the bounds of
the filesystem.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Initial results of FLEX_BG feature.
On Mon, 16 Jul 2007 00:34:57 -0600
Andreas Dilger [EMAIL PROTECTED] wrote:
On Jul 12, 2007 10:09 -0500, Jose R. Santos wrote:
@@ -1271,6 +1271,9 @@ static int ext4_check_descriptors (struc
ext4_debug (Checking group descriptors);
+ if (EXT4_HAS_INCOMPAT_FEATURE(sb, EXT4_FEATURE_INCOMPAT_FLEX_BG))
+ return 1;
+
for (i = 0; i sbi-s_groups_count; i++)
{
if (i == sbi-s_groups_count - 1)
It looks pretty straight forward to just change this code to leave
first_block at s_first_data_block, and leave last_block at ext4_blocks_count()
if FLEX_BG is set.
Sure. I'll add that.
Even with FLEX_BG we want to keep the group metadata within the bounds of
the filesystem.
Eventually, I want to be able to export the groups per flex groups so
that we can correctly calculate where the bounds of each block groups
metadata should be.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
-JRS
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Initial results of FLEX_BG feature.
On Wed, 11 Jul 2007 18:14:25 -0400
Theodore Tso [EMAIL PROTECTED] wrote:
On Wed, Jul 11, 2007 at 12:30:04AM -0500, Jose R. Santos wrote:
Right now what I've done is allocate the bitmaps and inode tables at the
beginning of each group of 64 BG. Still need to work on fsck since just
removing the restriction on were the bitmaps and inode table are
located still gives me errors of uninitialized inodes with dtime set.
Seems like fsck still expect inode information to be located at
specific locations within the disk.
Can you send me the patch which you were playing with? I might be
able to help you with this. It should be pretty straightforward to
remove the constraint on the inode table location.
Here is the kernel piece.
-JRS
---
fs/ext4/super.c |3 3 + 0 - 0 !
include/linux/ext4_fs.h |4 3 + 1 - 0 !
2 files changed, 6 insertions(+), 1 deletion(-)
Index: linux-2.6/fs/ext4/super.c
===
--- linux-2.6.orig/fs/ext4/super.c 2007-07-11 15:34:58.0 -0500
+++ linux-2.6/fs/ext4/super.c 2007-07-11 16:19:08.0 -0500
@@ -1271,6 +1271,9 @@ static int ext4_check_descriptors (struc
ext4_debug (Checking group descriptors);
+ if (EXT4_HAS_INCOMPAT_FEATURE(sb, EXT4_FEATURE_INCOMPAT_FLEX_BG))
+ return 1;
+
for (i = 0; i sbi-s_groups_count; i++)
{
if (i == sbi-s_groups_count - 1)
Index: linux-2.6/include/linux/ext4_fs.h
===
--- linux-2.6.orig/include/linux/ext4_fs.h 2007-07-11 15:34:58.0
-0500
+++ linux-2.6/include/linux/ext4_fs.h 2007-07-12 09:58:51.0 -0500
@@ -698,13 +698,15 @@ static inline int ext4_valid_inum(struct
#define EXT4_FEATURE_INCOMPAT_META_BG 0x0010
#define EXT4_FEATURE_INCOMPAT_EXTENTS 0x0040 /* extents support */
#define EXT4_FEATURE_INCOMPAT_64BIT0x0080
+#define EXT4_FEATURE_INCOMPAT_FLEX_BG 0x0200
#define EXT4_FEATURE_COMPAT_SUPP EXT2_FEATURE_COMPAT_EXT_ATTR
#define EXT4_FEATURE_INCOMPAT_SUPP (EXT4_FEATURE_INCOMPAT_FILETYPE| \
EXT4_FEATURE_INCOMPAT_RECOVER| \
EXT4_FEATURE_INCOMPAT_META_BG| \
EXT4_FEATURE_INCOMPAT_EXTENTS| \
-EXT4_FEATURE_INCOMPAT_64BIT)
+EXT4_FEATURE_INCOMPAT_64BIT| \
+EXT4_FEATURE_INCOMPAT_FLEX_BG)
#define EXT4_FEATURE_RO_COMPAT_SUPP(EXT4_FEATURE_RO_COMPAT_SPARSE_SUPER| \
EXT4_FEATURE_RO_COMPAT_LARGE_FILE| \
EXT4_FEATURE_RO_COMPAT_DIR_NLINK | \
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Initial results of FLEX_BG feature.
On Jul 11, 2007 00:30 -0500, Jose R. Santos wrote: On Tue, 10 Jul 2007 22:12:14 -0600 Andreas Dilger [EMAIL PROTECTED] wrote: You might also want to test out placement of the journal in the middle of the filesystem, the U. Wisconsin folks tested this in one of their papers and showed some noticable improvements. That isn't exactly related, but it is a relatively simple tweak to mke2fs/tune2fs to give it an allocation goal of group_desc[s_groups_count / 2].bg_inode_table (to put it past inode table in middle group). Make sense. Do you have a link to the paper? I don't have a URL, but if you search for IRON ext3 and go to Remzi's site it is called Analysis and Evolution of Journaling File Systems. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Initial results of FLEX_BG feature.
On Wed, Jul 11, 2007 at 12:30:04AM -0500, Jose R. Santos wrote: i think in the spirit of the original META_BG option, Ted had wanted to put all the bitmaps from EXT4_DESC_PER_BLOCK groups somewhere within the metagroup. It would also be interesting to see if moving ALL of the group metadata to a single location in the filesystem makes a bit difference. If not, then we may as well keep it spread out for safety. My original intention was that META_BG would place the bitmaps and inode tables at the beginning of each metagroup by default, but that the constraints about where to put the bitmaps and inode tables would be completely relaxed from the point of view of requirements by the kernel and e2fsck. Unfortunately while I had patches which removed the constraints checking, they never made it into mainline of either the kernel or e2fsprogs, sigh. - Ted - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Initial results of FLEX_BG feature.
On Wed, Jul 11, 2007 at 12:30:04AM -0500, Jose R. Santos wrote: Right now what I've done is allocate the bitmaps and inode tables at the beginning of each group of 64 BG. Still need to work on fsck since just removing the restriction on were the bitmaps and inode table are located still gives me errors of uninitialized inodes with dtime set. Seems like fsck still expect inode information to be located at specific locations within the disk. Can you send me the patch which you were playing with? I might be able to help you with this. It should be pretty straightforward to remove the constraint on the inode table location. It really should only be a check in e2fsck/super.c:check_super_block(), as far as I know. If you're seeing errors of unitialized inodes with dtime set, that sounds like maybe something else is going on. All of e2fsprogs should be referencing the inode table via fs-group_desc[group_num].bg_inode_table. See lib/ext2fs/inode.c, functions ext2fs_open_inode_scan(), get_next_blockgroup(), and ext2fs_read_inode_full(). - Ted - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
