[
https://issues.apache.org/jira/browse/HDFS-5443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13813630#comment-13813630
]
sathish commented on HDFS-5443:
-------------------------------
counts.add(cleanSubtreeRecursively(snapshot, prior, collectedBlocks,
removedINodes, priorDeleted, countDiffChange));
Even with this method also it is not deleting the files under the
recursively,when i debugged,i observed that,for one level of directory and file
structure this method works,if directory structure is large like
example:-
i have taken snaphot for root directory,under that directory there is one
subdirectory,under that one more like five levels,and the file we kept in fifth
level,and if we delete the first level directory,as the directory diff's are
maintaining only two levels for a particular deleted directory,parent of that
directory and child of that directory,it is not deleting that file and not
removing the zero sized blocks.
> Namenode can stuck in safemode on restart if it crashes just after addblock
> logsync and after taking snapshot for such file.
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: HDFS-5443
> URL: https://issues.apache.org/jira/browse/HDFS-5443
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: snapshots
> Affects Versions: 3.0.0, 2.2.0
> Reporter: Uma Maheswara Rao G
> Assignee: sathish
>
> This issue is reported by Prakash and Sathish.
> On looking into the issue following things are happening.
> .
> 1) Client added block at NN and just did logsync
> So, NN has block ID persisted.
> 2)Before returning addblock response to client take a snapshot for root or
> parent directories for that file
> 3) Delete parent directory for that file
> 4) Now crash the NN with out responding success to client for that addBlock
> call
> Now on restart of the Namenode, it will stuck in safemode.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
