Re: OT: why no file copy() libc/syscall ??

[Andreas Dilger <adilger@clusterfs.com>]

On Nov 10, 2003  23:14 -0500, Valdis.Kletnieks@vt.edu wrote:
> On Mon, 10 Nov 2003 23:03:26 EST, Daniel Gryniewicz said:
> > Plus a sys_copy() syscall could be used as a generic way for filesystems
> > to set up Copy-on-Write.  Right now, you'd need to have userspace call
> > sys-reiser4 or something like that.
> 
> This is fast turning into a creeping horror of aggregation.  I defy anybody
> to create an API to cover all the options mentioned so far and *not* have it
> look like the process_clone horror we so roundly derided a few weeks ago.

	int sys_copy(int fd_src, int fd_dst)

It is up to the filesystem to decide if both files are on the same device
and can be copied with a copy RPC (or whatever).  If the filesystem returns
-EOPNOTSUPP then the VFS goes into a simple readpages/writepages loop to do
the copy instead, maybe also copying ACLs or other things the VFS understands.

All of the "extra functionality" is being handled in the filesystem itself
and not the VFS or the API.  Copy-on-write is an fs-internal issue depending
on whether fs supports it, how it was mounted, etc.  Remote copy is also an
fs-internal issue depending on whether inodes are in same filesystem, support,
etc.  You might get into fun things like doing zero-copy.

Telling the filesystem we are doing a copy vs. a bunch of reads mixed
with a bunch of writes is just semantically something that the filesystem
should know about.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/