LWN.net Logo

NFS client updates

NFS client updates

Posted Jan 10, 2006 22:47 UTC (Tue) by brugolsky (subscriber, #28)
Parent article: Looking forward to 2.6.16

Lots of NFS goodness also merged, as detailed in NFS Client Updates Against 2.6.15 Available including:

  • NFS: Make stat() return updated mtimes after a write()
    The SuS states that a call to write() will cause mtime to be updated on the file. In order to satisfy that requirement, we need to flush out any cached writes in nfs_getattr(). Speed things up slightly by not committing the writes.
  • NFS: support large reads and writes on the wire
    Most NFS server implementations allow up to 64KB reads and writes on the wire. The Solaris NFS server allows up to a megabyte, for instance. Now the Linux NFS client supports transfer sizes up to 1MB, too. This will help reduce protocol and context switch overhead on read/write intensive NFS workloads, and support larger atomic read and write operations on servers that support them.
  • SUNRPC: Ensure that SIGKILL will always terminate a synchronous RPC call.
    ...and make sure that the "intr" flag also enables SIGHUP and SIGTERM to interrupt RPC calls too (as per the Solaris implementation).

The last item has been on my wishlist since 2.0.x; tears of joy are welling up in my eyes, it's like watching your kid graduate from college. :-p


(Log in to post comments)

NFS client updates

Posted Jan 11, 2006 2:15 UTC (Wed) by zblaxell (subscriber, #26385) [Link]

"SUNRPC: Ensure that SIGKILL will always terminate a synchronous RPC call."

I've been waiting for that patch since 0.98 or so. It's been broken so long I started to believe it was part of the spec. ;-)

NFS client updates

Posted Jan 11, 2006 23:50 UTC (Wed) by njhurst (guest, #6022) [Link]

What does this mean exactly, is it when a program is accessing an nfs file and the network goes down you can't kill the program?

NFS client updates

Posted Jan 12, 2006 0:53 UTC (Thu) by zblaxell (subscriber, #26385) [Link]

That's one of the effects.

The addition of lazy umounts and "umount -l" was a major step forward in
this area (you still couldn't kill the processes, but you could drop the
mount point so that you didn't get any more stuck on the dead NFS mount).
Solving the real problem of course is much better. ;-)

I also did things like mess with firewalls and NAT configuration until I
could convince the localhost to talk to its own NFS server (the tricky
part is doing this remotely with a live net-connected machine without
disrupting all of the server's other clients at the same time). This led
to "Stale NFS file handles" all over the place, but at least the RPC
calls would complete and the machine could get on with killing processes.

NFS client updates

Posted Jan 13, 2006 19:52 UTC (Fri) by pimlott (guest, #1535) [Link]

it's like watching your kid graduate from college. :-p
... after six years. :-)

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds