Date: Sun, 11 Feb 2001 12:25:08 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: freebsd-arch@FreeBSD.org Subject: Darwin VFSisms - VOP_COPYFILE() Message-ID: <Pine.NEB.3.96L.1010211114208.64780G-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
I've been perusing the Darwin source base for a while now, looking at
porting various features back and forth. While visiting Apple in
Cuptertino, I had a chance to discuss some of the VFS differences between
Darwin and recent FreeBSD. I was particular interested by the following
vnode operation that they added:
#
#% copyfile fvp U U U
#% copyfile tdvp L U U
#% copyfile tvp X U U
#
vop_copyfile {
IN WILLRELE struct vnode *fvp;
IN WILLRELE struct vnode *tdvp;
IN WILLRELE struct vnode *tvp;
IN struct componentname *tcnp;
IN int mode;
IN int flags;
};
The gist is that rather than manually copying a file in userspace, the
operation can be performed using an appropriate system call, pushed down
the VFS stack, and implemented by the file system. Much in the same way
as our rename() command maps into vop_rename at the VFS layer. For file
systems that implement efficient copying internally, this would be a great
boon. Two situations come to mind that make it relevant to us: recent
introduction of vop_copyonwrite() by Kirk in FFS, and the existence of
network file systems that offer a remote copy semantic (RPC), so that when
a client performs a copy, the file doesn't have to be shipped over the
network twice. My understanding is that Apple introduced this call for
AppleShare, which does support the remote copy semantic. I don't know,
but would guess that smb/cifs offers a similar RPC. Presumably the VOP
would have the opportunity to return EXDEV, as rename() does, to indicate
that the copy cannot be done magically, and that the userland utility
should fall back on doing it the old-fashioned way.
They provide a couple of flags for the flags field:
sys/fcntl.h:#define CPF_OVERWRITE 1
sys/fcntl.h:#define CPF_IGNORE_MODE 2
sys/fcntl.h:#define CPF_MASK (CPF_OVERWRITE|CPF_IGNORE_MODE)
I'm not sure if their construction of the VOP is right, and we should
discuss the semantics with regards to preserving various types of file
attributes (copyfile() might do the preservation a lot better than a
userland utility, for example), locking, etc. In particular, I'm not sure
I like the (mode) argument, which presumably specifies the mode of the new
file. I'd like copyfile() to preserve all existing protection attributes
(and other attributes) of the source file that the underlying file system
knows about. This would make it scale more easily into alternative file
system types where the protection of file extended attributes differ.
Anyway, your thoughts would be welcome. I'm not suggesting that we import
this immediately, rather, that if we find a rationale for doing so (if,
for example, smb/cifs does support a remote copy), that we try to
structure it in a way similar or identical to the Apple version to
increase interoperability.
BTW, it would be nice if documentation for VOP_COPYONWRITE() would turn up
someday. The idea of VFS is that it's a bit like an RPC interface space:
the interface is well-defined, and then various file systems implement
that interface. However, if there's no documentation, that makes it all a
bit ad hoc :-).
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org NAI Labs, Safeport Network Services
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010211114208.64780G-100000>