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@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)
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
