Hello Constantin,
On 5/29/06, Constantin Gonzalez <[EMAIL PROTECTED]> wrote:
Hi,
the current discussion on how to implement "undo" seems to circulate around
concepts and tweaks for replacing any "rm" like action with "mv" and then
fix the problems associated with namespaces, ACLs etc.
Why not use snapshots?
I hadn't considered that yet: I was quite fixated on solving this at
the ZPL level. :(
A snapshot-oriented implementation of undo would:
- Create a snapshot of the FS whenever anything is attempted that someone
might want to undo. This could be done even at the most fundamental level
(i.e. before any "zpool" or "zfs" command, where the potential damage to
be undone is biggest).
- The undo-feature would then exchange the live FS with the snapshot taken
prior to the revoked action. Just tweak one or two pointers and the undo
is done.
- This would transparently work with any app, user action, even admin action,
depending on where the snapshotting code would be hooked up to.
- As an alternative to undo, the user can browse the .zfs hierarchy in search
of that small file which got lost in an rm -rf orgy without having to restore
the snapshot with all the other unwanted files.
- When ZFS wants to reclaim blocks, it would start deleting the oldest
undo-snapshots.
- To separate undo-snapshots from user-triggered ones, the undo-code could
place its snapshots in .zfs/snapshots/undo .
Did I miss something why undo can't be implemented with snapshots?
No you didn't. Given the points you have raised, this does seem like
the way to go.
I'll dig around in the snapshot code and see if I can whip up
something more lightweight ie. a more targetted snapshot that can
snapshot a subset of the original filesystem.
Thanks for the suggestion! :)
--
Regards,
Jeremy
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
