[
https://issues.apache.org/jira/browse/HDFS-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13921394#comment-13921394
]
Todd Lipcon commented on HDFS-5477:
-----------------------------------
Also curious how you handle transactional updates for operations which span NS
and block management -- for example, changing the replication count of a file.
From the description in the document, it sounds like you ask the BM to make the
update to the block data, and then later update the inode. What if your RPC to
the BM were to time out? In that case you don't know whether the change was
made or not and it's unclear what to do on the namespace side.
> Block manager as a service
> --------------------------
>
> Key: HDFS-5477
> URL: https://issues.apache.org/jira/browse/HDFS-5477
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: namenode
> Affects Versions: 2.0.0-alpha, 3.0.0
> Reporter: Daryn Sharp
> Assignee: Daryn Sharp
> Attachments: Proposal.pdf, Proposal.pdf, Standalone BM.pdf,
> Standalone BM.pdf, patches.tar.gz
>
>
> The block manager needs to evolve towards having the ability to run as a
> standalone service to improve NN vertical and horizontal scalability. The
> goal is reducing the memory footprint of the NN proper to support larger
> namespaces, and improve overall performance by decoupling the block manager
> from the namespace and its lock. Ideally, a distinct BM will be transparent
> to clients and DNs.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
