No, I think he means just the opposite - that having a "copy(2)" syscall
would greatly _help_ SMB in that the copy could be done entirely at the
server side, rather than having to pull _all_ of the data to the client
and then sending it back again.
When I was working on another network storage system (formerly called
Lustre, don't know what it is called now) we had a "copy" primitive in
the VFS interface, and there were lots of useful things you could do
with it.
Consider the _very_ common case (that nobody has mentioned yet) where you
are editing a large file. When you write to the file, the editor copies
the file to a backup, then immediately truncates the original file and
writes the new data there. What would be _far_ preferrable is to just
"copy" the file to the new location within the kernel (zero work), and
then the new data will be the only I/O going to disk. This requires
some smarts on the part of the filesystem (essentially COW semantics),
but it well worth it on network storage. Even for "dumb" filesystems,
we could save the two (or one, with mmap) userspace copies, and optimize
to-boot (because we know the full size of the file in advance).
What about "link" you say? Well, emacs at least does a full copy instead
of a link, so that things like "cp -al linux-2.4.17 linux-2.4.17-new" will
work properly when you edit files in one of those trees. Not that I'm
an emacs user...
Cheers, Andreas
-- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/