Hi,
so we have two questions:
1. Is it really ZFS' job to provide an undo functionality?
2. If it turns out to be a feature that needs to be implemented by
ZFS, what is the better approach: Snapshot based or file-based?
My personal opinion on 1) is:
- The purpose of any Undo-like action is to provide a safety net to the user
in case she commits an error that she wants to undo.
- So, it depends on how we define "user" here. If by user we mean your regular
file system user with a GUI etc., then of course it's a matter of the
application.
- But if user=sysadmin, I guess a more fundamental way of implementing "undo" is
in order. We could either restrict the undo functionality to some admin
interface and force admins to use just that, then it would still be a feature
that the admin interface needs to implement.
But in order to save all admins from shooting themselves into their knees, the
best way would be to provide an admin-savvy safety net.
- Now, coming from the other side, ZFS provides a nice and elegant way of
implementing snapshots. That's where I count 1+1: If ZFS knew how to do
snapshots right before any significant administrator or user action and if
ZFS had a way of managing those snapshots so admins and users could easily
undo any action (including zfs destroy, zpool destroy, or just rm -rf /*),
then the benefit/investment ratio for implementing such a feature should
be extremely interesting.
One more step towards a truly foolproof filesystem.
But: If it turns out that providing an undo function via snapshots is not
possible/elegantly feasible/cheap or if there's any significant roadblock that
prevents ZFS from providing an undo feature in an elegant way, then it might not
be a good idea after all and we should just forget it.
So I guess it boils down to: Can the ZFS framework be used to implement an undo
feature much more elegantly than your classic filemanager while extending the
range of undo customers to even the CLI based admin?
Best regards,
Constantin
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.
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.
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).
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").
-Erik
--
Constantin Gonzalez Sun Microsystems GmbH, Germany
Platform Technology Group, Client Solutions http://www.sun.de/
Tel.: +49 89/4 60 08-25 91 http://blogs.sun.com/constantin/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
