We were running performance test on our test cluster.
The test itself is creating a tree of directories with files on the leafs in a depths first search fashion: there is a root and we create N directories in the root directory for the test, each mapper then starts in one of those directories and creates its own subtree with files on the leafs.
Then there is a read job that for each mapper does ls on the directory, chooses random element in ls, if it is a directory then repeat if it is a file then do read on the file. The files are 4K in size so the read time is small and we are mostly hitting the namenode with this job.
We were running the branch that had this fix and it also had read write locks for namenode instead of synchronized sections.
The version without fixes could only get namenode to use 175% cpu. With fixes in place we were using 750% cpu for read only load (when the second job was running on its own and 550% for read-write load when two jobs were running in parallel.
In the read-write mode the ration of reads to writes was 8:1 (800 read clients vs 100 write clients).
We are not putting the read-write locks in production in this iteration, seems we feel like we need to do more testing on it. As soon as I have some results for the branch with this fix only I will post my findings here.