[Gllug] Network traffic

Dylan Brewis dylan at shinyboots.org.uk
Tue Nov 27 18:31:36 UTC 2001


On Tuesday 27 November 2001 8:25 am, you wrote:
> >If i have an nfs filesystem (e.g. server:/pub ) mounted on a local client
> >(say as /import) do file operations such as copying which only relate to
> > the remote fs result in data travelling to the client and back to the
> > server, or is nfs 'intelligent' enough to to do the copy directly on the
> > remote machine?
>
> Data always travels across the network. The program doing the actual copy
> (in this case, cp) resides on the client machine. It doesn't know that the
> source and destination files are on an NFS filesystem. It just sees them
> as files that it can read and write, so that's what it does. That process
> of reading and writing involves the data flowing over the network. To
> do it any other way would require each application to have knowledge of
> where the file was held, and of the vagaries of every possible filesystem
> on which it may exist.
>
> Tet
I can't accept that explanation of how cp (etc.) operate (although I can see 
that the operation may cause the traffic as the software may be 'dumb' to 
that extent.). surely:

cp calls an api/kernel function/procedure/whatever to request or return the 
data.
The called routine passes the request/data to the relevant filesystem module 
to actually perform the file get or put.

Otherwise, cp would still need to know how to access any type of fs, and a 
new fs type would require a new version on cp to support it. I thought that 
was the point of modules (and api's, operating systems in general.)

With that in mind, there is no a priori reason why the nfs couldn't be 
written in such a way that the remote mount sendt a 'cp' like instruction to 
the server nfs when it knew the operation would result in redundant network 
traffic. This should be easy to resolve if the source and destination exist 
under the same export, possible but less straightforward if the source and 
dest are separately exported from the same server, and possibly not worth the 
effort for distinct server source and dest.

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug




More information about the GLLUG mailing list