[
https://issues.apache.org/jira/browse/HDFS-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861060#action_12861060
]
dhruba borthakur commented on HDFS-1093:
----------------------------------------
The numbers I listed were purely from the RPC module. In that case, each
createfile rpc could have created multiple components in the specified path.
similarly, a delete cal could have been recursive and could have deleted
multiple paths recursively.
> Improve namenode scalability by splitting the FSNamesystem synchronized
> section in a read/write lock
> ----------------------------------------------------------------------------------------------------
>
> Key: HDFS-1093
> URL: https://issues.apache.org/jira/browse/HDFS-1093
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: name-node
> Reporter: dhruba borthakur
> Assignee: dhruba borthakur
> Attachments: NNreadwriteLock.txt
>
>
> Most critical data structures in the NameNode (NN) are protected by a
> syncronized methods in the FSNamesystem class. This essentially makes
> critical code paths in the NN single-threaded. However, a large percentage of
> the NN calls are listStatus, getBlockLocations, etc which do not change
> internal data structures at all, these are read-only calls. If we change the
> FSNamesystem lock to a read/write lock, many of the above operations can
> occur in parallel, thus improving the scalability of the NN.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
