Another ocfs2 performance bug

Another ocfs2 performance bug

[Daniel Phillips]

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

Re: [Ocfs2-devel] Another ocfs2 performance bug

[Zach Brown]

> 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