zfs discuss - Apr 2010 - Making ZFS better: file/directory granularity in-place rollback

AFAIK, if you want to restore a snapshot version of a file or directory, you
need to use "cp" or such commands, to copy the snapshot version into
the
present.  This is not done in-place, meaning, the "cp" or whatever
tool must
read the old version of objects and write new copies of the objects.  You
may avoid the new disk space consumption if you have dedup enabled, but you
will not avoid the performance hit of requiring the complete read & write of
all the bytes of all the objects.  Performance is nothing like a simple
re-link of the snapshot restored object, and the newly restored objects are
not guaranteed identical to the old version - because "cp" or whatever
could
be changing permissions and timestamps and stuff, according to the behavior
of "cp" or whatever tool is being used. 

So the suggestion, or question is:  Is it possible or planned to implement a
rollback command, that works as fast as a link or re-link operation,
implemented at a file or directory level, instead of the entire filesystem?

Edward Ned Harvey wrote:
> AFAIK, if you want to restore a snapshot version of a file or directory,
you
> need to use "cp" or such commands, to copy the snapshot version
into the
> present.  This is not done in-place, meaning, the "cp" or
whatever tool must
> read the old version of objects and write new copies of the objects.  You
> may avoid the new disk space consumption if you have dedup enabled, but you
> will not avoid the performance hit of requiring the complete read &
write of
> all the bytes of all the objects.  Performance is nothing like a simple
> re-link of the snapshot restored object, and the newly restored objects are
> not guaranteed identical to the old version - because "cp" or
whatever could
> be changing permissions and timestamps and stuff, according to the behavior
> of "cp" or whatever tool is being used. 
>
> So the suggestion, or question is:  Is it possible or planned to implement
a
> rollback command, that works as fast as a link or re-link operation,
> implemented at a file or directory level, instead of the entire filesystem?
>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>   
Not to be a contrary person, but the job you describe above is properly 
the duty of a BACKUP system.  Snapshots *aren''t* traditional backups, 
though some people use them as such.   While I see no technical reason 
why snapshots couldn''t support some form of partial rollback,
there''s a
whole bunch of other features that Backup software provides that can''t 
be shoehorned directly into snapshots, so why bother trying to add a 
feature that should properly reside elsewhere in the system?


-- 
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA
Timezone: US/Pacific (GMT-0800)

> From: Erik Trimble [mailto:erik.trimble at oracle.com]
> 
> Not to be a contrary person, but the job you describe above is properly
> the duty of a BACKUP system.  Snapshots *aren''t* traditional
backups,
> though some people use them as such.   While I see no technical reason
> why snapshots couldn''t support some form of partial rollback,
there''s a
> whole bunch of other features that Backup software provides that
can''t
> be shoehorned directly into snapshots, so why bother trying to add a
> feature that should properly reside elsewhere in the system?
I don''t get what you''re talking about.  The disconnect is:  I
don''t know why
you would say this is a task for a backup system, when it''s ideally
suited
to the snapshot system, provided snapshots are available.  Allow me to
rephrase, and see if that changes anything...

One of the most valuable reasons to have snapshots is the ability for users
to restore or examine past versions of files instantly, without the need for
sysadmin assistance, or lag time waiting for tapes.  Snapshots augment the
backup system, but do not replace or eliminate the need for backups.

Given a filesystem, and some snapshots of that filesystem, all the data for
all the versions of all the files already exists on disk.  It required
essentially no time to link all the files to their respective snapshots.  It
would be nice, if you wanted to, to be able to link an old version of the
file to the present filesystem also in zero time.

This is not in any way a suggestion of eliminating or replacing your backup
system.  Backups are always needed in *addition* to snapshots.  Just incase
anything ever destroys the pool somehow.

> From: Erik Trimble [mailto:erik.trimble at oracle.com]
> 
> > So the suggestion, or question is:  Is it possible or planned to
> implement a
> > rollback command, that works as fast as a link or re-link operation,
> > implemented at a file or directory level, instead of the entire
> filesystem?
> >
> so why bother trying to add a
> feature that should properly reside elsewhere in the system?
That''s not a fair or unbiased question.  But the answer is easy anyway.
The
same reason why "zfs send" and "zfs receive" can be
sometimes used to backup
your filesystems.  It''s infinitely faster than the alternative,
"normal"
backup or cp commands.  (Of course not literally infinitely, but if you
estimate the "link" or "snapshot" time to be zero, then yes
infinitely.)

If you "zfs rollback somefile" it should theoretically be possible to
do it
in near-zero time, regardless of how large the file or directory is.

I know I''ve sat down with a user, whose simulation wasn''t
working anymore,
but it used to work a week ago.  And to help figure out what changed, I used
tar to restore 7 daily versions of his home directory, each of which took 10
minutes to restore.  So an hour later we were ready to start debugging.

Just saying theoretically it should be possible to do that in near-zero
time.  Right?

Edward Ned Harvey wrote:
>> From: Erik Trimble [mailto:erik.trimble at oracle.com]
>>
>>     
>>> So the suggestion, or question is:  Is it possible or planned to
>>>       
>> implement a
>>     
>>> rollback command, that works as fast as a link or re-link
operation,
>>> implemented at a file or directory level, instead of the entire
>>>       
>> filesystem?
>>     
>> so why bother trying to add a
>> feature that should properly reside elsewhere in the system?
>>     
>
> That''s not a fair or unbiased question.  But the answer is easy
anyway.  The
> same reason why "zfs send" and "zfs receive" can be
sometimes used to backup
> your filesystems.  It''s infinitely faster than the alternative,
"normal"
> backup or cp commands.  (Of course not literally infinitely, but if you
> estimate the "link" or "snapshot" time to be zero, then
yes infinitely.)
>
> If you "zfs rollback somefile" it should theoretically be
possible to do it
> in near-zero time, regardless of how large the file or directory is.
>
> I know I''ve sat down with a user, whose simulation wasn''t
working anymore,
> but it used to work a week ago.  And to help figure out what changed, I
used
> tar to restore 7 daily versions of his home directory, each of which took
10
> minutes to restore.  So an hour later we were ready to start debugging.
>
> Just saying theoretically it should be possible to do that in near-zero
> time.  Right
Dunno. Conceptually, yes, it should be trivial.  In reality, I don''t 
know the code well enough to say so, as there may be unintended 
consequences (or, more likely, unforeseen time costs).



-- 
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA
Timezone: US/Pacific (GMT-0800)