An alternative to undelete is snapshotting. This also gives protection against "logical data corruption" like virus infections or data changes because of bugs or simply human failure. I am a huge proponent of solving as much as possible problems with a single solution. And, afaik, snapshotting is being worked on or is at least on the roadmap. Cheers, Fred Met vriendelijke groeten, * Fred van Zwieten * *Enterprise Open Source Services* * Consultant* *(vrijdags afwezig)* *VX Company IT Services B.V.* *T* (035) 539 09 50 mobiel (06) 41 68 28 48 *F* (035) 539 09 08 *E* fvzwieten at vxcompany.com *I* www.vxcompany.com On Mon, Dec 31, 2012 at 4:01 PM, Vijay Bellur <vbellur at redhat.com> wrote: > On 12/30/2012 09:42 PM, Stephan von Krawczynski wrote: > > If I delete > > something on a disk that is far from being full it is just plain dumb to > > really erase this data from the disk. It won't help anyone. It will only > hurt > > you if you deleted it accidently. Read my lips: free disk space is wasted > > space, just like free mem is wasted mem. > > And_that_ is the true reason for undelete. It won't hurt anybody, and > will > > help some. And since it is the true goal of a fs to organise data on a > drive > > it is most obvious that "undelete" (you may call it lazy-delete) is a > very > > basic fs feature and_not_ an add-on patched onto it. > > Have you explored xlators/features/trash in the source tree? Does that > fit your requirements? If that does, code clean up in trash translator > and exposing undelete (via trash xlator) as a tunable through the > gluster volume set interface is not complex. > > -Vijay > > > > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20121231/249fed8f/attachment.html>
