Hi guys,
Reading all the files in a big directory tree takes at least four times
as long on ocfs2 as ext3.
# ocfs2: Copy a kernel tree to /dev/null
mount -tocfs2 /dev/hdb /big
time find /big/linux-2.6.16-rc3 -type f -exec cp {} /dev/null \;
real 1m54.933s <===
user 0m0.896s
sys 0m1.844s
time find /big/linux-2.6.16-rc3 -type f -exec cp {} /dev/null \;
real 0m14.301s
user 0m5.172s
sys 0m9.093s
# ext3: Copy a kernel tree to /dev/null
mount -text3 /dev/hdb /big
time find /big/linux-2.6.16-rc3 -type f -exec cp {} /dev/null \;
real 0m23.899s <===
user 0m4.672s
sys 0m9.513s
time find /big/linux-2.6.16-rc3 -type f -exec cp {} /dev/null \;
real 0m14.198s
user 0m5.168s
sys 0m8.977s
Regards,
Daniel
> Reading all the files in a big directory tree takes at least four times
> as long on ocfs2 as ext3.
> real 1m54.933s <===
> real 0m23.899s <===
Can you doctor your scripts to show at least some overview of the IO
patterns? Just the amount of reads and writes would be a good start,
but something like graphing blktrace output would be wildly instructive.
My first guess would be the known difference between OCFS2's full-block
inodes and ext3's habit of packing lots of inode structs into a block.
Secondary guesses would be lack of directory read-ahead, bad IO patterns
based on allocation policy, etc..
- z