[
https://issues.apache.org/jira/browse/HDFS-5453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854493#comment-13854493
]
Milind Bhandarkar commented on HDFS-5453:
-----------------------------------------
Suresh,
Indeed, let's agree to disagree, and move on.
In another Jira, trying to make namespace pluggable (patch coming soon), Colin
has expressed the need for fine-grain locking. (So, I am not alone. Even in
LevelDB based impl, you would need fine grain locking, in case there is a cache
miss, right?)
Thinking more about it, I think locking is a property of the namespace, not the
namenode. If the namespace is implemented using a transactional store, then
namenode should not lock at all.
In my opinion, namenode should just be a stateless RPC server, with namespace
and block management as services. In that case, locking should be removed from
NN, and moved to namesystem. If current NS impl wants to lock everything, that
is ok.
What do you think?
> Support fine grain locking in FSNamesystem
> ------------------------------------------
>
> Key: HDFS-5453
> URL: https://issues.apache.org/jira/browse/HDFS-5453
> Project: Hadoop HDFS
> Issue Type: New Feature
> Components: namenode
> Affects Versions: 2.0.0-alpha, 3.0.0
> Reporter: Daryn Sharp
> Assignee: Daryn Sharp
>
> The namesystem currently uses a course grain lock to control access. This
> prevents concurrent writers in different branches of the tree, and prevents
> readers from accessing branches that writers aren't using.
> Features that introduce latency to namesystem operations, such as cold
> storage of inodes, will need fine grain locking to avoid degrading the entire
> namesystem's throughput.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
