Hello, this is with reference to bug #6343653, "want to quickly "copy" a file from a snapshot". After a short dig through source code, the issue is that ''mv'' will do a copy because the rename syscall fails for files on different filesystems (snapshots are mounted as separate filesystems from the host filesystem). There are 2 ways around this: 1) Hack/Modify the rename syscall to special case the ZFS snapshot situation 2) Implement a special internal ZFS call, which is only used by something like "zfs mv <source> <destination>" Implementation wise, I prefer 2. Thoughts anyone? :) -- Regards, Jeremy
Jeremy Teo wrote:> Hello, > > this is with reference to bug #6343653, "want to quickly "copy" a file > from a snapshot". > > After a short dig through source code, the issue is that ''mv'' will do > a copy because the rename syscall fails for files on different > filesystems (snapshots are mounted as separate filesystems from the > host filesystem). > > There are 2 ways around this: > > 1) Hack/Modify the rename syscall to special case the ZFS snapshot > situation > > 2) Implement a special internal ZFS call, which is only used by > something like "zfs mv <source> <destination>" > > Implementation wise, I prefer 2. Thoughts anyone? :)Hi Jeremy, While I agree that option 2 has certain merits, I think you would be better off with special-casing the syscall. It should not be all that difficult (famous las words) to handle the special case, and for anybody working on that part of the code after you, it should be simple to keep track of what''s going on. That''s the essential difference to option (2) - if you change the zfs code to special-case handle this system call, then whoever updates the system call has to know that you''ve done this and keep track of the zfs part as well as all the other bits. I''m sure you can special-case handle the syscall in an elegant manner, too :) best regards, James C. McPherson
I would suggest taking a version of approach (1), myself. Rather than special-casing ZFS, we could issue a VOP_CROSS_RENAME (or some such call) if the source and destination directory were on different file systems implemented by the same filesystem module. If this returned failure (e.g. the ENOSYS likely to be returned by file systems which do not implement this new VOP), the rename would fail as it does today, and mv would perform its copy/delete sequence instead. (Why a new VOP? Compatibility with existing file systems which may assume that rename has already performed the same file system check.) I would recommend this because it''s more general. For instance, Apple''s AFP protocol allows a file to be renamed/moved from one mounted file system to another if both are on the same file server. This allows a large file to be moved without having it cross the network twice. I think that CIFS may have the same functionality. This would allow VFS modules implementing those to expose the function to Solaris. This message posted from opensolaris.org