From owner-freebsd-arch Sun Feb 11 9:25:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id AC38137B491 for ; Sun, 11 Feb 2001 09:25:09 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1BHP8h76621 for ; Sun, 11 Feb 2001 12:25:08 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 11 Feb 2001 12:25:08 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: freebsd-arch@FreeBSD.org Subject: Darwin VFSisms - VOP_COPYFILE() Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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