hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Suresh Srinivas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-4114) Remove the BackupNode and CheckpointNode from trunk
Date Thu, 17 Apr 2014 18:13:19 GMT

    [ 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

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

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
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

This message was sent by Atlassian JIRA

View raw message