[
https://issues.apache.org/jira/browse/HADOOP-432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469632
]
Yoram Arnon commented on HADOOP-432:
------------------------------------
> won't remove a checkpoint until its older than the interval
> Yes, that would be a useful feature. Calling moveToTrash() on any path that
> begins with the trash's root should cause it to be immediately removed. +1
Cool. One more reason: sometimes you'd want to expunge data that has just been
deleted, while it's still in the current trash, to free up some space *now*.
> So the RPC load on the namenode is minimized.
right. a single invocation may result in a large load on the namenode (under a
lock?)
It would be nice if the load on the namenode from expunging were capped, for
example if files were deleted in the background, no more than some amount per
second or something.
It's somewhat disturbing because it's not controlled. There will probably be
some cron job that expunges automatically, and in some cases, when many files
were deleted since the last expunge, the namenode will misbehave for its
regular clients.
> support undelete, snapshots, or other mechanism to recover lost files
> ---------------------------------------------------------------------
>
> Key: HADOOP-432
> URL: https://issues.apache.org/jira/browse/HADOOP-432
> Project: Hadoop
> Issue Type: Improvement
> Components: dfs
> Reporter: Yoram Arnon
> Assigned To: Doug Cutting
> Attachments: trash.patch, undelete12.patch, undelete16.patch,
> undelete17.patch
>
>
> currently, once you delete a file it's gone forever.
> most file systems allow some form of recovery of deleted files.
> a simple solution would be an 'undelete' command.
> a more comprehensive solution would include snapshots, manual and automatic,
> with scheduling options.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
