[
https://issues.apache.org/jira/browse/HDFS-6315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13990076#comment-13990076
]
Haohui Mai commented on HDFS-6315:
----------------------------------
bq. Do keep in mind that hopefully in the next few months there will not be a
globally held FSN so don't entirely remove the FSD lock believing the FSN lock
will cover for it.
The ultimate goal here is to allow FSD only implement the mappings between
names and inodes. That way locking is an implementation detail but not part of
the interface. FSD can be implemented in lock-free data structure which does
not require locking at all. Making the FSN lock more fine-grained is definitely
useful but it is orthogonal.
bq. I'm curious what you have in mind. HDFS-5693 appears to be a valuable
change. I thoughts deletes used to do something similar while collecting
blocks, but that whole region of code has been changed.
Based on my initial surveys, in the majority (>90%) cases that both FSD lock
and FSN lock are held together. They can be combined with little performance
lost in today's codebase. In longer term FSD might be lock-free as I mentioned
above.
> Decouple recording edit logs from FSDirectory
> ---------------------------------------------
>
> Key: HDFS-6315
> URL: https://issues.apache.org/jira/browse/HDFS-6315
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: Haohui Mai
> Assignee: Haohui Mai
> Attachments: HDFS-6315.000.patch, HDFS-6315.001.patch
>
>
> Currently both FSNamesystem and FSDirectory record edit logs. This design
> requires both FSNamesystem and FSDirectory to be tightly coupled together to
> implement a durable namespace.
> This jira proposes to separate the responsibility of implementing the
> namespace and providing durability with edit logs. Specifically, FSDirectory
> implements the namespace (which should have no edit log operations), and
> FSNamesystem implement durability by recording the edit logs.
--
This message was sent by Atlassian JIRA
(v6.2#6252)