>>Running dbench 128 on ext2 mounted with delalloc and Andrew's
>>patches from http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.8/
>>was 7.5x faster than 2.5.8 vanilla and 1.5x faster than
> Wow, good stuff - I'll have to pull those down
Hmm, I had to run e2fsck -f twice on the filesystem that ran
dbench, tiobench, bonnie++ on nfs, and osdb. The filesystem
was showing 52% used and is normally 1% used before/after
testing. No big files on the fs. The directory where
bonnie++ on nfs runs had some temporary directories that
were not deletable. A bunch of files/directories were in
lost+found after e2fsck. After removing the files, the
fs was back to 1% used.
I backed up and did mke2fs in case there was any
pre-existing/lingering corruption. So keep your karma
up and test on a test box. :)
--
Randy Hron
[email protected] wrote:
>
> >>Running dbench 128 on ext2 mounted with delalloc and Andrew's
> >>patches from http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.8/
> >>was 7.5x faster than 2.5.8 vanilla and 1.5x faster than
>
> > Wow, good stuff - I'll have to pull those down
>
> Hmm, I had to run e2fsck -f twice on the filesystem that ran
> dbench, tiobench, bonnie++ on nfs, and osdb. The filesystem
> was showing 52% used and is normally 1% used before/after
> testing. No big files on the fs. The directory where
> bonnie++ on nfs runs had some temporary directories that
> were not deletable. A bunch of files/directories were in
> lost+found after e2fsck. After removing the files, the
> fs was back to 1% used.
>
ho-hum. Presumably an unreservepage() got lost somewhere
in the diff shuffling.
All I'm doing with the delayed-allocation code at present
is keeping the diffs up to date. I haven't even compiled
that stuff for over a week. All work at present is against
dallocbase-70-writeback. It's probably not a good use of
your time to test anything beyond that. Sorry about that.
I'll leave the later diffs available so anyone who's interested
can see the multipage bio assembly stuff, but "dont use".
-