1. 07 Oct, 2008 2 commits
  2. 09 Jul, 2008 1 commit
  3. 16 May, 2008 1 commit
  4. 29 Apr, 2008 2 commits
  5. 19 Apr, 2008 1 commit
  6. 19 Mar, 2008 2 commits
    • Chuck Lever's avatar
      NFS: Save the values of the "mount*=" mount options · 3f8400d1
      Chuck Lever authored
      
      Save the value of the mountproto= mountport= mountvers= and mountaddr=
      options so that these values can be displayed later via
      nfs_show_options().
      
      This preserves the intent of the original mount options, should the file
      system need to be remounted based on what's displayed in /proc/mounts.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      3f8400d1
    • Chuck Lever's avatar
      NFS: Save the value of the "port=" mount option · f22d6d79
      Chuck Lever authored
      
      During a remount based on the mount options displayed in /proc/mounts, we
      want to preserve the original behavior of the mount request.  Let's save
      the original setting of the "port=" mount option in the mount's nfs_server
      structure.
      
      This allows us to simplify the default behavior of port setting for NFSv4
      mounts: by default, NFSv2/3 mounts first try an RPC bind to determine the
      NFS server's port, unless the user specified the "port=" mount option;
      Users can force the client to skip the RPC bind by explicitly specifying
      "port=<value>".
      
      NFSv4, by contrast, assumes the NFS server port is 2049 and skips the RPC
      bind, unless the user specifies "port=".  Users can force an RPC bind for
      NFSv4 by explicitly specifying "port=0".
      
      I added a couple of extra comments to clarify this behavior.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      f22d6d79
  7. 29 Feb, 2008 1 commit
  8. 30 Jan, 2008 19 commits
  9. 12 Dec, 2007 1 commit
    • Trond Myklebust's avatar
      NFSv2/v3: Fix a memory leak when using -onolock · 5cef338b
      Trond Myklebust authored
      
      Neil Brown said:
      > Hi Trond,
      > 
      > We found that a machine which made moderately heavy use of
      > 'automount' was leaking some nfs data structures - particularly the
      > 4K allocated by rpc_alloc_iostats.
      > It turns out that this only happens with filesystems with -onolock
      > set.
      
      > The problem is that if NFS_MOUNT_NONLM is set, nfs_start_lockd doesn't
      > set server->destroy, so when the filesystem is unmounted, the
      > ->client_acl is not shutdown, and so several resources are still
      > held.  Multiple mount/umount cycles will slowly eat away memory
      > several pages at a time.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      Acked-by: default avatarNeilBrown <neilb@suse.de>
      5cef338b
  10. 06 Dec, 2007 1 commit
  11. 17 Oct, 2007 1 commit
  12. 09 Oct, 2007 4 commits
  13. 28 Sep, 2007 1 commit
  14. 16 Jul, 2007 1 commit
  15. 11 Jul, 2007 2 commits