[
https://issues.apache.org/jira/browse/HDFS-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13973221#comment-13973221
]
Suresh Srinivas commented on HDFS-4114:
---------------------------------------
[~cos] and [~shv], I commented more than 5 months ago, responding back with
questions -
https://issues.apache.org/jira/browse/HDFS-4114?focusedCommentId=13841600&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13841600.
After a long silence, patches have been posted to take this jira further.
bq. I don't understand the rush, guys. There's a legit use of the mechanism as
Konstantin has stated earlier in the JIRA. It might not be widely used at the
moment, but it provides certain benefits to some of us in the community.
BackupNode was introduced in 2008/2009. I do not see any one using it. [~cos],
have you used it?
Coming to benefits, can you explain what they are? Please review my comments. I
do not see any benefits at this time, other than serving to confuse and create
unnecessary work. What are the plans you have for BackupNode and please help us
understand the reason for retaining it.
bq. BackupImage class had two tiny patches since February
2013.BackupJournalManager has been touched 5 times in 2+ years. BackupNode was
modified 6 times in about the same time, and so on.
BackupNode related code just does not exist in these classes only. It is in
FSEditLog, FSImage etc. as well. There are also many unnecessary protocols.
Please review the patch posted to see the extent of code associated. If you
count all these places, there are many other changes that had to be made during
HA, retry Cache, FSImage and editlog related work. That said, even a single
unnecessary change made to parts that are no longer relevant is one too many.
This issue has been brought up by several folks. Active committers to HDFS no
longer see any reason to retain this functionality. Other active committers and
contributors, if you disagree, please speak up.
These are possible things I can see going forward:
- Please post responses to my comments earlier. Please post what you plan to do
with BackupNode. Please justify your veto based on technical reasons.
- We can comment out the code or we can start creating jiras for BackupNode
changes only to be picked up by [~shv]. The problem I see with the second
option is, having to wait for [~shv] to make progress on any work that requires
change to BackupNode.
Going silent and not responding to comments in a timely manner and only
responding when code changes are about to be made (with someone putting all the
effort to make the changes) is not being nice to others in the community.
> Remove the BackupNode and CheckpointNode from trunk
> ---------------------------------------------------
>
> Key: HDFS-4114
> URL: https://issues.apache.org/jira/browse/HDFS-4114
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: Eli Collins
> Assignee: Suresh Srinivas
> Attachments: HDFS-4114.000.patch, HDFS-4114.001.patch, HDFS-4114.patch
>
>
> Per the thread on hdfs-dev@ (http://s.apache.org/tMT) let's remove the
> BackupNode and CheckpointNode.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
