Patchwork [bigalloc] e2fsprogs: change root-inode to extent-mapped

login
register
mail settings
Submitter Robin Dong
Date July 20, 2011, 5:38 a.m.
Message ID <1311140311-20242-1-git-send-email-hao.bigrat@gmail.com>
Download mbox | patch
Permalink /patch/105582/
State Rejected
Headers show

Comments

Robin Dong - July 20, 2011, 5:38 a.m.
From: Robin Dong <sanbai@taobao.com>

After creating more than 1000 files in root directory on ext4 of bigalloc,
the kernel reports many error messages like:

[181126.730911] EXT4-fs error (device sda4): ext4_ind_map_blocks:1015: inode #2: comm falloc: Can't allocate blocks for non-extent mapped inodes with bigalloc
[181126.735945] EXT4-fs error (device sda4): ext4_ind_map_blocks:1015: inode #2: comm falloc: Can't allocate blocks for non-extent mapped inodes with bigalloc

because the root inode of a new ext4 filesystem is type of block-mapped
even use mke2fs with "-O extent,bigalloc".

So change root inode to extent-mapped when do "mke2fs" if the option has "extent".

Signed-off-by: Robin Dong <sanbai@taobao.com>
Cc: Ted Ts'o <tytso@mit.edu>
---
 lib/ext2fs/mkdir.c |   21 ++++++++++++++++++++-
 1 files changed, 20 insertions(+), 1 deletions(-)
Theodore Ts'o - July 20, 2011, 2:28 p.m.
On Jul 20, 2011, at 1:38 AM, hao.bigrat@gmail.com wrote:

> From: Robin Dong <sanbai@taobao.com>
> 
> After creating more than 1000 files in root directory on ext4 of bigalloc,
> the kernel reports many error messages like:
> 
> [181126.730911] EXT4-fs error (device sda4): ext4_ind_map_blocks:1015: inode #2: comm falloc: Can't allocate blocks for non-extent mapped inodes with bigalloc
> [181126.735945] EXT4-fs error (device sda4): ext4_ind_map_blocks:1015: inode #2: comm falloc: Can't allocate blocks for non-extent mapped inodes with bigalloc
> 
> because the root inode of a new ext4 filesystem is type of block-mapped
> even use mke2fs with "-O extent,bigalloc".

This is fixed already in the "next" branch of e2fsprogs

http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=commit;h=1afb468b9a80031b39eab37272709f45727fb221

This commit was checked in well over a month ago.  If you're not using the latest next branch of e2fsprogs, you really should....   this wasn't the only bigalloc-related mke2fs bug that was fixed, and e2fsck should now be working as well with bigalloc.

-- Ted

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Andreas Dilger - July 20, 2011, 3:52 p.m.
On 2011-07-19, at 11:38 PM, hao.bigrat@gmail.com wrote:
> 
> After creating more than 1000 files in root directory on ext4 of bigalloc,
> the kernel reports many error messages like:
> 
> [181126.730911] EXT4-fs error (device sda4): ext4_ind_map_blocks:1015: inode #2: comm falloc: Can't allocate blocks for non-extent mapped inodes with bigalloc
> [181126.735945] EXT4-fs error (device sda4): ext4_ind_map_blocks:1015: inode #2: comm falloc: Can't allocate blocks for non-extent mapped inodes with bigalloc
> 
> because the root inode of a new ext4 filesystem is type of block-mapped
> even use mke2fs with "-O extent,bigalloc".

That reminds me of a question I had with bigalloc - are htree directories supported with bigalloc?  For a 1MB bigalloc chunksize it would mean a fanout of 256k, or a maximum directory size of 256GB with only a single level.

Any thoughts about increasing the directory size beyond 2GB?

Cheers, Andeas--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Theodore Ts'o - July 20, 2011, 5:49 p.m.
On Wed, Jul 20, 2011 at 09:52:49AM -0600, Andreas Dilger wrote:
> 
> That reminds me of a question I had with bigalloc - are htree
> directories supported with bigalloc?  For a 1MB bigalloc chunksize
> it would mean a fanout of 256k, or a maximum directory size of 256GB
> with only a single level.

Yes, htree directories are supported with bigalloc; but it still works
on *blocks*, whereas *clusters* are just used for allocation purposes.

> 
> Any thoughts about increasing the directory size beyond 2GB?
> 

I think the best way to do that is to support more than two levels of
directories.  I seem to recall your telling me that one of your team
had prototyped something like this a while back?  Or is my memory
playing tricks on me?

							- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/lib/ext2fs/mkdir.c b/lib/ext2fs/mkdir.c
index 86c65da..d4b8d37 100644
--- a/lib/ext2fs/mkdir.c
+++ b/lib/ext2fs/mkdir.c
@@ -39,6 +39,9 @@  errcode_t ext2fs_mkdir(ext2_filsys fs, ext2_ino_t parent, ext2_ino_t inum,
 	ext2_ino_t		scratch_ino;
 	blk64_t			blk;
 	char			*block = 0;
+	int			max;
+	struct ext3_extent	*ex;
+	struct ext3_extent_header *eh;
 
 	EXT2_CHECK_MAGIC(fs, EXT2_ET_MAGIC_EXT2FS_FILSYS);
 
@@ -84,7 +87,23 @@  errcode_t ext2fs_mkdir(ext2_filsys fs, ext2_ino_t parent, ext2_ino_t inum,
 	inode.i_uid = inode.i_gid = 0;
 	ext2fs_iblk_set(fs, &inode, 1);
 	/* FIXME-64 */
-	inode.i_block[0] = blk;
+	if (fs->super->s_feature_incompat &
+	    EXT3_FEATURE_INCOMPAT_EXTENTS) {
+		eh = (struct ext3_extent_header *) &inode.i_block[0];
+		eh->eh_depth = 0;
+		eh->eh_entries = 1;
+		eh->eh_magic = ext2fs_cpu_to_le16(EXT3_EXT_MAGIC);
+		max = (sizeof(inode.i_block) - sizeof(*eh)) /
+			sizeof(struct ext3_extent);
+		eh->eh_max =  ext2fs_cpu_to_le16(max);
+		ex = EXT_FIRST_EXTENT(eh);
+		ex->ee_block = 0;
+		ex->ee_start = ext2fs_cpu_to_le32(blk & 0xFFFFFFFF);
+		ex->ee_start_hi = ext2fs_cpu_to_le16(blk >> 32);
+		ex->ee_len = 1;
+		inode.i_flags |= EXT4_EXTENTS_FL;
+	} else
+		inode.i_block[0] = blk;
 	inode.i_links_count = 2;
 	inode.i_size = fs->blocksize;