[
https://issues.apache.org/jira/browse/HDFS-5474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13822408#comment-13822408
]
Hudson commented on HDFS-5474:
------------------------------
FAILURE: Integrated in Hadoop-Mapreduce-trunk #1608 (See
[https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1608/])
HDFS-5474. Deletesnapshot can make Namenode in safemode on NN restarts.
Contributed by Sathish. (jing9:
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1541685)
* /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
*
/hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java
> Deletesnapshot can make Namenode in safemode on NN restarts.
> ------------------------------------------------------------
>
> Key: HDFS-5474
> URL: https://issues.apache.org/jira/browse/HDFS-5474
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: snapshots
> Reporter: Uma Maheswara Rao G
> Assignee: sathish
> Fix For: 2.3.0
>
> Attachments: HDFS-5474-001.patch, HDFS-5474-002.patch
>
>
> When we deletesnapshot, we are deleting the blocks associated to that
> snapshot and after that we do logsync to editlog about deleteSnapshot.
> There can be a chance that blocks removed from blocks map but before log sync
> if there is BR , NN may finds that block does not exist in blocks map and
> may invalidate that block. As part HB, invalidation info also can go. After
> this steps if Namenode shutdown before actually do logsync, On restart it
> will still consider that snapshot Inodes and expect blocks to report from DN.
> Simple solution is, we should simply move down that blocks removal after
> logsync only. Similar to delete op.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
