[
https://issues.apache.org/jira/browse/HDFS-5453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13853067#comment-13853067
]
Suresh Srinivas commented on HDFS-5453:
---------------------------------------
[~ebortnik], which release did you use for this bench mark?
bq. CPU-bound workloads most of the time is wasted on concurrency control.
Can you elaborate on what this is, as far as namenode is concerned?
bq. what if the namespace impl does not require writing to disk as edit log,
but just memory to memory replication over low-latency network?
I do not know how this would work. It is certainly not going to be everyone's
deployment model. I also assume it works with entire cluster/data center
shutdown.
bq. Will you restrict it by not allowing fine-grain locking?
No one is restricting fine-grain locking. I want to understand the tradeoffs
between performance gain and possible complexity to the code.
> 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)
