On Tue, 2007-08-28 at 00:25 -0500, Eric Sandeen wrote:
> Ugh. brain clearly not fully engaged... here we go:
> Tried out Ted's git tree + all pending patches today, and
> immediately oopsed on a mkdir thanks to this in
> (there are 54 BUGs and BUG_ONs in this file...!)
> I think something like this patch is needed?
Thanks for catching this and the fix. I saw the same kernel oops today
when rum mballoc on fsstress (mkdir). I just added this fix to the patch
queue with some comments.
> Signed-off-by: Eric Sandeen <[email protected]>
> Index: ext4.git/fs/ext4/extents.c
> --- ext4.git.orig/fs/ext4/extents.c
> +++ ext4.git/fs/ext4/extents.c
> @@ -2535,7 +2535,10 @@ int ext4_ext_get_blocks(handle_t *handle
> ar.goal = ext4_ext_find_goal(inode, path, iblock);
> ar.logical = iblock;
> ar.len = allocated;
> - ar.flags = EXT4_MB_HINT_DATA;
> + if (S_ISREG(inode->i_mode))
> + ar.flags = EXT4_MB_HINT_DATA;
> + else
> + ar.flags = 0;
I see. We set the flags to zero here to avoid doing in-core
preallocation for directory files later.
Well, I am not sure whether it's worth the effort to support in-core
preallocation for directory files. But I don't see hard reason we cannot
do this. My understanding is: this is the new in-core preallocation
which does a should not depend on extents or any on-disk format changes.
Alex, any comments?
> newblock = ext4_mb_new_blocks(handle, &ar, &err);
> if (!newblock)
> goto out2;
> 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