Re: [ANNOUNCEMENT PATCH COW] proof of concept impementation of cowlinks

[Steve French <smfltc@us.ibm.com>]

It would not be helpful to take a userspace request to perform a file
(or directory) copy operation and break it into open/sendfile/close by
passing file handles to the network filesystem and have this work for
SMB/CIFS - there is no equivalent network protocol operation.  It also
makes the operation much, much harder to make atomic (since two systems
are involved) and makes error handling and recovery for network
filesystems much harder since inconsistent client and server state have
to be considered if the copy operation is broken into pieces on the
clien (it is also slower - a single copy operation on the network is the
absolute optimal case - minimizes the expensive network latency - the
roundtrip delay - open/sendfile/close sends at a minimum three times as
many but likely four with an extra lookup or two)

Currently copy file (or copy directory for that matter) as both speced
(and is implemented in various servers) in the SMB/CIFS network
filesystem protocol takes in effect four parameters (there is no handle
based file copy):

a source pathname,  and source export (actually SMB tree identifier for
a share, but in effect the same thing) 
a target pathname, and target export (actually SMB tree identifier for a
share, but in effect the same thing) 
And the shares (exports) referenced have to be on the same server

Trying to ignore the 1st file open

On Tue, 2004-05-11 at 05:02, Jörn Engel wrote:
> On Mon, 10 May 2004 15:26:02 -0400, Jan Harkes wrote:
> > On Mon, May 10, 2004 at 05:53:59PM +0200, Jörn Engel wrote:
> > > A real problem is that copyfile() has all errno's from create(),
> > > sendfile() and unlink() combined, which doesn't make error handling in
> > > userspace easy.  "It could be this, that or another error" is the kind
> > > of mess I always hated about Windows, so I should try to do a little
> > > better.
> > 
> > Well, if you leave the create and unlink up to the application and
> > simply pass open filedescriptors to copyfile... But then it would be
> > equivalent to your new sendfile.
> > 
> > Copyfile can trivially be implemented in libc. I don't see why it would
> > have to be a system call. If a network filesystem wants to optimize the
> > file copying it could do this based on the sendfile data. If source and
> > destination are within the same filesystem and we're copying the whole
> > file starting at offset 0, send a copyfile RPC.
> 
> Can you explain this to Steve?  I'm still quite clueless about network
> filesystems, but it sounded as if such an optimization was impossible
> to do in cifs without a combined create/copy/unlink_on_error system
> call.
> 
> If your suggestion works and the network filesystems can be changed to
> work independently of a struct file*, I agree with you that copyfile()
> is a stupid idea and should be forgotten.
> 
> Jörn