On Wed, Jan 15, 2014 at 12:22:14PM -0800, Darrick J. Wong wrote: > A dumpe2fs would be nice, but I think I have enough here to speculate: It's trivial to reproduce. Just create a 1GB file, run mkfs.ext3, then mount with ext4 and dd a 10MB file onto the filesystem. > The data blocks are all sequential, which looks like what one would expect from > mballoc. Is your complaint is that the *IND blocks are not inline with the > data blocks, like what ext3 did? The problem is that the indirect blocks are nowhere near where the file's data is. It'd be perfectly okay if they were at the beginning of the range of blocks used for the file's data. > FWIW, ext3 did something like this: > (0-11):6144-6155, (IND):6156, (12-1035):6157-7180, (DIND):7181, (IND):7182, > (1036-2059):7183-8206, (IND):8207, (2060-2559):8208-8707 > > I think the behavior that you're seeing is ext4 trying to keep the mapping > blocks close to the inode table to avoid fragmenting the file -- see > ext4_find_near() in indirect.c. There's an XXX comment in ext4_find_goal() > that implies that someone might have wanted to tie in with mballoc, which I > suppose you could use to restore the ext3 behavior... but there's no way to do > that. ... I tried a few tests setting goal to different things, but evidently I'm not managing to convince mballoc to put the file's data close to my goal block, something in that mess of complicated logic is making it ignore the goal value I'm passing in. -ben -- "Thought is the essence of where you are now." -- 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
