hey All,
On Tue, 2006-05-30 at 16:50 +0200, Constantin Gonzalez Schmitz wrote:
> - 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, what if the user was able to specify which applications they wanted
such a safety net for (thus lessening the load on the filesystem,
watching *every* delete) - or were able to specify a few sub-directories
they wanted to take special care with ?
[ eg. "ZFS, please provide me undo capability for files
in /home/timf/Documents/plans-to-takeover-world when I'm using
nautilus" ]
With a tiny bit of DTrace hackery, you could have something like:
------ snapshot-on-delete.d --------
#!/usr/sbin/dtrace -qws
syscall::unlink:entry
/pid==$1/
{
this->file = copyinstr(arg0);
system ("/usr/sbin/take-undo-snapshot.sh %s",this->file);
}
------------------------------------
Something like:
% ./snapshot-on-delete.d `pgrep nautilus`
Where the shell script "take-undo-snapshot.sh" would take another
snapshot in some known namespace, up to some a pre-defined limit, if
that file was found to be resident on a zfs filesystem (and optionally
in some given directory)
Now, it probably will scale badly if you have hundreds of users, running
hundreds of applications, each one invoking a shell script on each file
delete, and as Neil pointed out, many many snapshots aren't cheap. But
as a proof-of-concept, this would work fine.
It'd be interesting to see how badly people wanted this functionality,
before boiling the ocean (again!) to provide it :-)
Of course, "redo" is a little trickier, as your application would need
to know about the snapshot namespace, but at least your data is safe.
cheers,
tim
> - 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
> >
>
--
Tim Foster, Sun Microsystems Inc, Operating Platforms Group
Engineering Operations http://blogs.sun.com/timf
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
