> From: Erik Trimble [mailto:erik.trim...@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? _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
