Re: [RFC] extents support for EXT3

From: Ed Sweetman
Date: Fri Aug 29 2003 - 11:22:51 EST


Alex Tomas wrote:
Ed Sweetman (ES) writes:


ES> in the kernels that would boot (for some reason test4's videodev
ES> driver is borked so i used the mm patchset) passed the serio drivers,
ES> init was unable to be found, no matter what even though it mounted the
ES> root fs and the root fs is not as far as i can tell when booting on
ES> older kernels, corrupted. I'm writing now in mozilla from the very
ES> system but with extents turned off. I'm somewhat afraid though that
ES> even though i didn't mount the partitions with the extents option,
ES> that the patch may still be having an adverse effect. Right now
ES> things seem pretty stable but last night apt was hanging while
ES> generating locales reproducably causing the entire kernel to lose the
ES> ability to do anything to the fs. This was all being tested on
ES> test3-mm1. I am aware that mm does have some patches to ext3 that
ES> aren't in the main kernel i believe. perhaps the xattr stuff is
ES> conflicting in some way? I really have no way of testing the linus
ES> tree directly because the drivers i use wont compile.

first of all, once fs gets mounted with extents support any newly created
files/dirs will be stored in extents-format. thus, if you remount that fs
w/o extents support you won't be able to access those files/dirs

I really propose you don't use extents on a partitions you care about for a while.

I was testing this with only a single partition mounted with extents enabled when benchmarking. Ext3 gave no messages of being mounted afterbootup with or without extents so to make sure i had extents enabled i booted with all my partitions with the extents option. I suspect then my problems began. I'm completely unaware of the extent of the damage enabling extents has done since most of the important things were opened, not created during my extents use. In any case it may be that the reason why init is not able to be found is because i used apt and upgraded my system ...and I dont remember if i had extents enabled at the time or not. If my init is in extents format though, then why is a patched kernel able to read it with extents not being enabled via the omunt option where as kernels without the patch cannot. Is extents able to be read from a fs even when it's not mounted with the option but not written? I'm kinda confused, this aspect of extents wasn't in the original email.

ES> All in all though, when it was enabled, i saw really no difference
ES> from when it was not enabled. dbench 16 gave me ~140MB/sec either
ES> way. md5summing large files resulted in equal performance as well. I
ES> got nothing even close to the kind of performance increases you showed
ES> in the first mail.

quite interesting result. could you help me to investigate that?
it would be great to go through following steps:
1) create fresh ext3 fs
2) mount it w/o extents option
3) run dbench 16 for few times (say, 4)
make sure it performs on that filesystem (cd <mntpoint>; dbench -c ... 16)
4) unmount fs
5) recreate that fs
6) mount it with extents option
'EXT3-fs: file extents enabled' should be printed in logs
7) run dbench 16 for few times
8) unmount that fs and take a look in logs, you should see stats info about
extents usage

thank you!

i'm going to try and boot a kernel without the extents patch (so far hasn't been possible) and run dbench again and see if i get different numbers. I'm almost suspecting extents being enabled no matter what i mount the fs's as.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/