Ok! I've been slacking on this bug for way too long. But here are my experiments and the data.
WHAT ARE THE FILES IN THIS TARBALL?
patch is the diff of 2 minor optimizations I made in hadoop-23.
I then ran Slive on clean HDFS installations for 0.23 and 0.204. These are the commands I ran. First create 200000 files (hopefully that's what it does... though its not important if it doesn't)
bin/hadoop org.apache.hadoop.fs.slive.SliveTest -duration 50 -dirSize 1225 -files 200000 -maps 4 -readSize 104850,104850 -writeSize 104850,104850 -appendSize 104850,104850 -replication 1,1 -reduces 1 -blockSize 1024,1024 -mkdir 0,uniform -rename 0,uniform -append 0,uniform -delete 0,uniform -ls 0,uniform -read 0,uniform -create 100,uniform and then delete 50000 files (again, hopefully that's what it does)
bin/hadoop org.apache.hadoop.fs.slive.SliveTest -duration 50 -dirSize 1225 -files 50000 -maps 4 -readSize 104850,104850 -writeSize 104850,104850 -appendSize 104850,104850 -replication 1,1 -reduces 1 -blockSize 1024,1024 -mkdir 0,uniform -rename 0,uniform -append 0,uniform -delete 100,uniform -ls 0,uniform -read 0,uniform -create 0,uniform
I do this 3 times. Hence the 6 files
<branch>.C200 <- create 200k files
<branch>.C200D50 <- delete 50k files
In the last run, I delete 500000 files, and use jvisualvm to create snapshots
while I am profiling. The two snapshot*.npm files can be loaded into jvisualvm.
Create seems to be twice as fast in 0.23. So I'm not too worried about that.
Delete on the other hand is a lot slower. I've tried optimizing, but I don't
know if there's much else that can be done. A huge reason is probably this:
In 0.20 we were using the synchronized variable, which although is 2-7.5x
faster (as reported in the blog), is unfair. In 0.23 we are using a fair
ReentrantReadWriteLock. This is obviously going to be slower and since
writeLock() is what's taking the most amount of time (ref the jvisualvm
profile), I am led to believe that we must incur the performance hit in order
to be fair.
Comments are welcome. Please let me know your thoughts.
@Todd: These are on the latest branch-23 74fd5cb929adc926a13eb062df7869894c0cc013