hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konstantin Shvachko (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-432) support undelete, snapshots, or other mechanism to recover lost files
Date Thu, 14 Dec 2006 21:37:22 GMT
    [ http://issues.apache.org/jira/browse/HADOOP-432?page=comments#action_12458610 ] 
Konstantin Shvachko commented on HADOOP-432:

I agree with Doug and was advocating for the pure client implementation of the thrash-bin
from the very beginning.
But now after so many iterations I'm hesitant about going back to the drawing board stage.

The main reason for implementing it on the name-node was the timestamp issue. Clients do not
have synchronized
clocks, so they need to contact the name-node to get a proper timestamp to stamp files being
Since it has to send a request to the name-node any way why not just ask the name-node to
perform the operation.
That kind of logic.

What is good in Wendy's implementation.
- All trash logic is contained in a separate class, the name-node code and data structures
have not been affected.
- There is a way to configure parameters so that trash never starts: no wast of space, no
trash daemon.

> support undelete, snapshots, or other mechanism to recover lost files
> ---------------------------------------------------------------------
>                 Key: HADOOP-432
>                 URL: http://issues.apache.org/jira/browse/HADOOP-432
>             Project: Hadoop
>          Issue Type: Improvement
>          Components: dfs
>            Reporter: Yoram Arnon
>         Assigned To: Wendy Chien
>         Attachments: 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

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message