1. 13 7月, 2011 4 次提交
  2. 15 6月, 2011 1 次提交
  3. 30 5月, 2011 2 次提交
  4. 12 5月, 2011 1 次提交
  5. 28 4月, 2011 1 次提交
    • T
      NFSv4: Ensure we request the ordinary fileid when doing readdirplus · 28331a46
      Trond Myklebust 提交于
      When readdir() returns a directory entry for the root of a mounted
      filesystem, Linux follows the old convention of returning the inode
      number of the covered directory (despite newer versions of POSIX declaring
      that this is a bug).
      To ensure this continues to work, the NFSv4 readdir implementation requests
      the 'mounted-on-fileid' from the server.
      
      However, readdirplus also needs to instantiate an inode for this entry, and
      for that, we also need to request the real fileid as per this patch.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      28331a46
  6. 25 3月, 2011 4 次提交
  7. 24 3月, 2011 2 次提交
  8. 15 3月, 2011 1 次提交
  9. 12 3月, 2011 11 次提交
  10. 07 1月, 2011 3 次提交
  11. 17 12月, 2010 1 次提交
    • C
      NFS: Simplify ->decode_dirent() calling sequence · 573c4e1e
      Chuck Lever 提交于
      Clean up.
      
      The pointer returned by ->decode_dirent() is no longer used as a
      pointer.  The only call site (xdr_decode() in fs/nfs/dir.c) simply
      extracts the errno value encoded in the pointer.  Replace the
      returned pointer with a standard integer errno return value.
      
      Also, pass the "server" argument as part of the nfs_entry instead of
      as a separate parameter.  It's faster to derive "server" in
      nfs_readdir_xdr_to_array() since we already have the directory's inode
      handy.  "server" ought to be invariant for a set of entries in the
      same directory, right?
      
      The legacy versions of decode_dirent() don't use "server" anyway, so
      it's wasted work for them to derive and pass "server" for each entry.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Tested-by: NJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      573c4e1e
  12. 23 11月, 2010 1 次提交
  13. 25 10月, 2010 3 次提交
  14. 24 10月, 2010 3 次提交
    • B
      NFS: Readdir plus in v4 · 82f2e547
      Bryan Schumaker 提交于
      By requsting more attributes during a readdir, we can mimic the readdir plus
      operation that was in NFSv3.
      
      To test, I ran the command `ls -lU --color=none` on directories with various
      numbers of files.  Without readdir plus, I see this:
      
      n files |    100    |   1,000   |  10,000   |  100,000  | 1,000,000
      --------+-----------+-----------+-----------+-----------+----------
      real    | 0m00.153s | 0m00.589s | 0m05.601s | 0m56.691s | 9m59.128s
      user    | 0m00.007s | 0m00.007s | 0m00.077s | 0m00.703s | 0m06.800s
      sys     | 0m00.010s | 0m00.070s | 0m00.633s | 0m06.423s | 1m10.005s
      access  | 3         | 1         | 1         | 4         | 31
      getattr | 2         | 1         | 1         | 1         | 1
      lookup  | 104       | 1,003     | 10,003    | 100,003   | 1,000,003
      readdir | 2         | 16        | 158       | 1,575     | 15,749
      total   | 111       | 1,021     | 10,163    | 101,583   | 1,015,784
      
      With readdir plus enabled, I see this:
      
      n files |    100    |   1,000   |  10,000   |  100,000  | 1,000,000
      --------+-----------+-----------+-----------+-----------+----------
      real    | 0m00.115s | 0m00.206s | 0m01.079s | 0m12.521s | 2m07.528s
      user    | 0m00.003s | 0m00.003s | 0m00.040s | 0m00.290s | 0m03.296s
      sys     | 0m00.007s | 0m00.020s | 0m00.120s | 0m01.357s | 0m17.556s
      access  | 3         | 1         | 1         | 1         | 7
      getattr | 2         | 1         | 1         | 1         | 1
      lookup  | 4         | 3         | 3         | 3         | 3
      readdir | 6         | 62        | 630       | 6,300     | 62,993
      total   | 15        | 67        | 635       | 6,305     | 63,004
      
      Readdir plus disabled has about a 16x increase in the number of rpc calls and
      is 4 - 5 times slower on large directories.
      Signed-off-by: NBryan Schumaker <bjschuma@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      82f2e547
    • B
      NFS: readdir with vmapped pages · 56e4ebf8
      Bryan Schumaker 提交于
      We can use vmapped pages to read more information from the network at once.
      This will reduce the number of calls needed to complete a readdir.
      Signed-off-by: NBryan Schumaker <bjschuma@netapp.com>
      [trondmy: Added #include for linux/vmalloc.h> in fs/nfs/dir.c]
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      56e4ebf8
    • B
      NFS: decode_dirent should use an xdr_stream · babddc72
      Bryan Schumaker 提交于
      Convert nfs*xdr.c to use an xdr stream in decode_dirent.  This will prevent a
      kernel oops that has been occuring when reading a vmapped page.
      Signed-off-by: NBryan Schumaker <bjschuma@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      babddc72
  15. 24 9月, 2010 1 次提交
  16. 18 9月, 2010 1 次提交
    • J
      nfs: make sillyrename an async operation · d3d4152a
      Jeff Layton 提交于
      A synchronous rename can be interrupted by a SIGKILL. If that happens
      during a sillyrename operation, it's possible for the rename call to
      be sent to the server, but the task exits before processing the
      reply. If this happens, the sillyrenamed file won't get cleaned up
      during nfs_dentry_iput and the server is left with a dangling .nfs* file
      hanging around.
      
      Fix this problem by turning sillyrename into an asynchronous operation
      and have the task doing the sillyrename just wait on the reply. If the
      task is killed before the sillyrename completes, it'll still proceed
      to completion.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Reviewed-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      d3d4152a