Constantin Gonzalez wrote On 05/29/06 02:50,:
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?
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?
Well creating a snapshot isn't exactly free. It requires flushing out
all the current in progress transactions to ensure the containing
transaction group is committed on disk. This can be quick or can take
a few seconds depending on the current load. So it isn't practical to
snapshot before every remove - but perhaps a courser grain might work?
Best regards,
Constantin
--
Neil
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
