On Mon, May 29, 2006 at 11:00:29PM -0700, Erik Trimble wrote: > Once again, I hate to be a harpy on this one, but are we really > convinced that having a "undo" (I'm going to call is RecycleBin from now > on) function for file deletion built into ZFS is a good thing? > > Since I've seen nothing to the contrary, I'm assuming that we're doing > this by changing the actual effects of an "unlink(2)" sys lib call > against a file in ZFS, and having some other library call added to take > care of actual deletion.
No. The idea is a FIFO queue, bounded in space. There is no explicit 'actual deletion'. Things just pass in one way and out the other once the space is needed. If you accidentally delete something, you can quickly go back and get it, but it's not a replacement for regular snapshots. For example, you might do: # zfs set undelete=1m home/eschrock Which would keep just 1 MB of deleted files around, which would allow for recovery of most useful file types (text files, documents, etc). > Even with it being a ZFS option parameter, I can see soooo many places > that it breaks assumptions and causes problems that I can't think it's a > good thing to blindly turn on for everything. There is no change in assumption. 'rm' will still remove a file, only that it's deletion may be delayed. This is an optional feature, and is no different than 'rm' in the face of snapshots. If you don't like it, don't use the feature (just as you probably wouldn't want snapshots). There is no "really really remove" command - the point is that the user doesn't have to think about this, it "just works". > And, I've still not seen a good rebuttal to the idea of moving this up > to the Application level, and using a new library to implements the > functionality (and requires Apps to specifically (and explicitly) > support RecycleBin in the design). I've tried over and over, with several different points: - doesn't work over NFS/CIFS (recycle bin 'location' may not be accessible on all hosts, or may require cross-network traffic to delete a file). - inherently user-centric, not filesystem-centric (location of stored file depends on who's doing the deletion) - requires application changes (which means it can _NEVER_ scale beyond a handful of apps) - ignores the predominant need (accidental 'rm') These are real requirements, whether or not you think they are good. > You will notice that Windows does this. The Recycle Bin is usable from > within Windows Explorer, but if you use "del" from a command prompt, it > actually deletes the file. I see no reason why we shouldn't support the > same functionality (i.e. RecycleBin from within Nautilus (as it already > does), and true deletion via "rm"). Except that the whole point of this RFE is that people _want_ 'rm' to have undelete functionality. The whole world doesn't use Nautilius/insertapphere. I'm all for having some common 'recycle bin' functionality (though I think no one will use it beyond a handful of apps), but that is independent of this RFE. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
