| Message ID | 1311140311-20242-1-git-send-email-hao.bigrat@gmail.com |
|---|---|
| State | Rejected, archived |
| Headers | show |
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
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
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
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;