In answer to the first question, the processor on the client would be executing the application code but the application's files would be being read on the NFS server and then provided to the client. In effect, NFS is strictly implementing the filesystem. The load on the server will be proportional to the read/write I/O activity of the client.
For the second question, earlier versions of NFS for Linux used the NFS V2 protocol which is strictly synchronous in terms of read/write operations. To make matters worse, the implementation defaulted to 1k buffers which resulted in a hideous amount of overhead. One other point about NFS V2 is that it has a strict 32 bit file size limitation which I believe means you can't read/write files greater than 4 gigs (might be 2 depending on whether this is a signed 32 bit integer). The locking problems that may have been alluded to are of the kind where the machine controlling the file locks and byte range might lose track of which client was holding which lock. File locking is a common problem area especially when you are dealing with interoperability issues, i.e. different flavors of server and client. -Alex ----- Original Message ----- From: "Kenneth E. Lussier" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 29, 2002 3:34 PM Subject: NFS Question > Hi All, > > I have a couple of (simple) questions about NFS, and I'm sure someone > here can smack me with a clue-stick... > > 1) If applications are mounted via NFS, and someone runs the > application, is the processor on the NFS server or the client system > used? (I'm pretty sure it's the client, but I was told different today, > so now I'm not sure..) > > 2) What sort of problems are there with NFS on Linux? I have heard that > there are file locking problems, but nothing really in depth. Anyone > care to elaborate? > > I think that that is all for now. > > TIA, > Kenny > -- > -------------------------------------------------------------------------- -- > "Tact is just *not* saying true stuff" -- Cordelia Chase > > Kenneth E. Lussier > Sr. Systems Administrator > Zuken, USA > PGP KeyID CB254DD0 > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCB254DD0 > > > _______________________________________________ > gnhlug-discuss mailing list > [EMAIL PROTECTED] > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss > _______________________________________________ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
