[
https://issues.apache.org/jira/browse/HDFS-14586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16870863#comment-16870863
]
He Xiaoqiao commented on HDFS-14586:
------------------------------------
It makes sense at first sight. But I am also going to concern if it will break
emptier when we set very short time for {{emptierInterval}}.
IMO the root cause is creating checkpoint path at the un-proper time since we
cost time to delete the expired trash directory. Based on that, the direct way
is creating checkpoint path before delete checkpoint, as following, Just one
suggestions, FYI.
{code:java}
trash.createCheckpoint(trashRoot.getPath(), new Date(now));
trash.deleteCheckpoint(trashRoot.getPath(), false);
{code}
{code:java}
we need to keep checkpoint generated timestamp to measure something.
{code}
would like offer some more details? I think it is better to get access time or
modify time of INode if you want `measure something`. Thanks again.
> Trash missing delete the folder which near timeout checkpoint
> -------------------------------------------------------------
>
> Key: HDFS-14586
> URL: https://issues.apache.org/jira/browse/HDFS-14586
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: hu yongfa
> Assignee: hu yongfa
> Priority: Major
> Attachments: HDFS-14586.001.patch
>
>
> when trash timeout checkpoint coming, trash will delete the old folder first,
> then create a new checkpoint folder.
> as the delete action may spend a long time, such as 2 minutes, so the new
> checkpoint folder created late.
> at the next trash timeout checkpoint, trash will skip delete the new
> checkpoint folder, because the new checkpoint folder is
> less than a checkpoint interval.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
