(I'm going to combine Constantine & Eric's replies together, so I
apologize for the possible confusion):
On Tue, 2006-05-30 at 16:50 +0200, Constantin Gonzalez Schmitz wrote:
> 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.
Agreed. :-)
>
> - 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.
>
As an admin, that certainly sounds noble. However, given Eric's
implementation details:
On Tue, 2006-05-30 at 09:48 -0700, Eric Schrock wrote:
> 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
I can't imagine that any admin would set this FIFO space anything more
than a very small amount. Personally, there will always be pressure from
the user base to have more usable disk space (without actually buying
more disk), so best case I can picture is that the FIFO is under 1GB for
a TB filesystem. Now, for critical filesystems (such as root), which
have a relatively fixed size, I could see setting it to say 100mb for a
10GB root partition.
The problem here is that it's _very_ easy to blow right through the FIFO
size limit with just a single "rm -rf". Or, if you are on a filesystem
that has multiple users, the likelihood that several of us combine to
exceed the limit (and, thus, making it likely that what you wanted to
"restore" is gone for good) is much higher. This limits the usefulness
of the feature considerably.
> - 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.
>
The problem is that you are attempting to divine user INTENTIONS (did I
_really_ want to do that). That's a losing proposition. You will always
be wrong (at best) in a significant minority of the time, which will be
far above the people's threshold for tolerance. Take a look at the "-i"
function for rm. Do you know how annoying that is for an admin (and,
that virtually no admin ever uses it)? Yet, it provides about the same
level of protection as "undo" would.
Part of being an administrator is learning proper procedures. One of the
biggest problems with Windows is that it provides the ILLUSION that any
JoeBlow can be an administrator. Yet, time and time again Windows has
huge failures linked directly to incompetent (or untrained)
administrators. We don't want to go down this road with Solaris.
Providing tools which give an 80% solution is generally very useful in
the user space, but is VERY frustrating (and, in my opinion,
counterproductive) in the admin space.
Accidental file deletion (or, as Constantine pointed advanced, other
admin commands such as "zpool destroy") is a problem. HOWEVER, you want
to provide only a 100% solution to the problem. Am I going to like a
solution which "sorta-kinda-might" restore the file or one which WILL
restore the file.
What I'm trying to say is that a competent admin will STILL have to
maintain version controlled config files, and back things up on a
regular basis. ZFS snapshots are very nice in these cases, as they
provide a PERMANENT picture of things before changes are made. ZFS undo
doesn't alleviate the need to do any of this, but it CAN provide the
ILLUSION that you can skip this.
Short of a full version control and complete history retention for all
files in a ZFS filesystem, filesystem-level undo isn't a good idea. The
person asking for the RFE doesn't (in my opinion) have a competent admin
staff, and is asking for a BandAid to a problem requiring skilled
surgeons.
Yes, that is an exaggeration, and yes, there are times when I've
fat-fingered something and said "aaaargh. I want that back right now!".
But, once again, proper sysadmin procedures already protect one from
that. Guaranteed.
> 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
On Tue, 2006-05-30 at 09:48 -0700, Eric Schrock wrote:
>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).
So, how am I supposed to get back a file from your proposed "undo"
solution? Does every directory have a .zfs/deleted directory inside it,
with the "temporarily deleted" files residing in there? If not, how do
I access a ZFS undo directory across NFS? If so, how is this any
different than having a .recyclebin directory for each normal
directory?
> - inherently user-centric, not filesystem-centric (location of stored
> file depends on who's doing the deletion)
with Application-level RecycleBin, the assumption is that all the
clients have a common API to call (some lib installed locally), that
implements the generic RecycleBin technology across all filesystem
types. Take a look at Samba's implementation of RecycleBin - it works
just fine for user-centric applications.
> - requires application changes (which means it can _NEVER_ scale >
beyond
> a handful of apps)
>- ignores the predominant need (accidental 'rm')
>
Which is EXACTLY what is needed. The RFE is for "accidental rm". There
are only going to be a small handful of applications that really can
make use of an "undo" function. Those apps are going to be the ones
which allow the user to directly manipulate the filesystem.
Put it another way: look at the $HOME/tmp directory. How many
applications create/delete files there on a very regular basis? You
sure you want ZFS to put those into the FIFO "undo"-reserved space?
Or /var/run. Or /tmp. Or any of a dozen different Applications which
regularly create and delete files themselves, without any user
intervention. If I enable ZFS undo on the / filesystem to protect
myself, think of all the apps which do this kind of create/delete to
things. So, how long will your FIFO last again?
--
Erik Trimble
Java System Support
Mailstop: usca14-102
Phone: x17195
Santa Clara, CA
Timezone: US/Pacific (GMT-0800)
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
