Jeremy Teo wrote:
Hello,
with reference to bug id #4852821: user undo
I have implemented a basic prototype that has the current functionality:
1) deleted files/directories are moved to /your_pool/your_fs/.zfs/deleted
Unfortunately, it is non-trivial to completely reproduce the namespace
of deleted files: for now, deleting "/foo/bar" will result in
".zfs/deleted/bar".
I had exactly the same issue when I implemented this for ext2 years ago
:-) [ I never finished it - got bored with it since I didn't actually
need it myself :-) ].
2) As a result of 1, deleted files move out of .zfs/deleted in FIFO.
Ie. if you remove /foo/bar twice, the most recent copy will be the one
remaining in .zfs/deleted.
That seems okay, and you have that issue even if you do reproduce the
namespace, for example:
$ rm foo/bar
< you now have .zfs/deleted/foo/bar >
$ mkdir foo/bar
< you now have .zfs/deleted/foo/bar and foo/bar >
$ rm foo/bar
Now what do we do ? the FIFO seems reasonable to me, if you need better
than that use snapshots.
3) If another user deletes /foo/bar, and you try to delete /foo/bar,
you will be denied permissions. Again, this is due to namespace
clashes.
Thats not good and I think this would violate POSIX requirements for
unlink(2).
I'm leaning towards completely reproducing the namespace, but would
like to get a feel for whether the benefits outweigh the code
complexity. Advice would be appreciated.
POSIX compliance is a must. The FIFO idea actually sounds pretty good.
How does this interact with snapshots ?
Also, I presume I can request-sponsor for 4852821 and get someone from
the zfs team to mentor me?
The request-sponsor is really for when you are done. If you want code
help I've found asking on [EMAIL PROTECTED] gets great feedback.
--
Darren J Moffat
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
