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 > ext4_mb_new_group_pa() > > BUG_ON(!S_ISREG(ac->ac_inode->i_mode)); > > (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 <sandeen@xxxxxxxxxx> > > > 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? Mingming > 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 majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
