[ 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 deleted. 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 options. -- 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
