1. 08 10月, 2008 1 次提交
  2. 07 10月, 2008 1 次提交
  3. 10 7月, 2008 1 次提交
  4. 17 5月, 2008 1 次提交
  5. 29 4月, 2008 2 次提交
  6. 20 4月, 2008 1 次提交
  7. 20 3月, 2008 2 次提交
    • C
      NFS: Save the values of the "mount*=" mount options · 3f8400d1
      Chuck Lever 提交于
      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: NChuck Lever <chuck.lever@oracle.com>
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      3f8400d1
    • C
      NFS: Save the value of the "port=" mount option · f22d6d79
      Chuck Lever 提交于
      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: NChuck Lever <chuck.lever@oracle.com>
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      f22d6d79
  8. 29 2月, 2008 1 次提交
  9. 30 1月, 2008 19 次提交
  10. 12 12月, 2007 1 次提交
    • T
      NFSv2/v3: Fix a memory leak when using -onolock · 5cef338b
      Trond Myklebust 提交于
      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: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Acked-by: NNeilBrown <neilb@suse.de>
      5cef338b
  11. 07 12月, 2007 1 次提交
  12. 17 10月, 2007 1 次提交
  13. 10 10月, 2007 4 次提交
  14. 29 9月, 2007 1 次提交
  15. 17 7月, 2007 1 次提交
  16. 11 7月, 2007 2 次提交