1. 09 5月, 2016 1 次提交
    • A
      nfs: per-name sillyunlink exclusion · 884be175
      Al Viro 提交于
      use d_alloc_parallel() for sillyunlink/lookup exclusion and
      explicit rwsem (nfs_rmdir() being a writer and nfs_call_unlink() -
      a reader) for rmdir/sillyunlink one.
      
      That ought to make lookup/readdir/!O_CREAT atomic_open really
      parallel on NFS.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      884be175
  2. 18 2月, 2016 1 次提交
    • K
      pnfs/blocklayout: fix a memeory leak when using,vmalloc_to_page · c8975706
      Kinglong Mee 提交于
      unreferenced object 0xffffc90000abf000 (size 16900):
        comm "fsync02", pid 15765, jiffies 4297431627 (age 423.772s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 a0 c2 19 00 88 ff ff  ................
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<ffffffff8174d54e>] kmemleak_alloc+0x4e/0xb0
          [<ffffffff811b9b91>] __vmalloc_node_range+0x231/0x280
          [<ffffffff811b9c2a>] __vmalloc+0x4a/0x50
          [<ffffffffa02c9ec1>] ext_tree_prepare_commit+0x231/0x2e0 [blocklayoutdriver]
          [<ffffffffa02c700e>] bl_prepare_layoutcommit+0xe/0x10 [blocklayoutdriver]
          [<ffffffffa0596a6c>] pnfs_layoutcommit_inode+0x29c/0x330 [nfsv4]
          [<ffffffffa0596b13>] pnfs_generic_sync+0x13/0x20 [nfsv4]
          [<ffffffffa0585188>] nfs4_file_fsync+0x58/0x150 [nfsv4]
          [<ffffffff81228e5b>] vfs_fsync_range+0x4b/0xb0
          [<ffffffff81228f1d>] do_fsync+0x3d/0x70
          [<ffffffff812291d0>] SyS_fsync+0x10/0x20
          [<ffffffff81757def>] entry_SYSCALL_64_fastpath+0x12/0x76
          [<ffffffffffffffff>] 0xffffffffffffffff
      
      v2, add missing include header
      Signed-off-by: NKinglong Mee <kinglongmee@gmail.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      c8975706
  3. 01 1月, 2016 3 次提交
  4. 29 12月, 2015 1 次提交
  5. 24 11月, 2015 1 次提交
  6. 04 11月, 2015 1 次提交
  7. 16 10月, 2015 2 次提交
  8. 08 10月, 2015 1 次提交
  9. 08 9月, 2015 1 次提交
  10. 28 8月, 2015 2 次提交
  11. 20 8月, 2015 1 次提交
  12. 24 6月, 2015 1 次提交
  13. 16 6月, 2015 3 次提交
  14. 24 4月, 2015 1 次提交
  15. 28 3月, 2015 1 次提交
  16. 19 2月, 2015 2 次提交
  17. 14 2月, 2015 1 次提交
  18. 06 2月, 2015 2 次提交
  19. 04 2月, 2015 6 次提交
  20. 25 1月, 2015 2 次提交
  21. 24 1月, 2015 1 次提交
  22. 26 11月, 2014 1 次提交
  23. 13 11月, 2014 1 次提交
  24. 01 10月, 2014 1 次提交
  25. 25 9月, 2014 1 次提交
    • N
      NFSv4: use exponential retry on NFS4ERR_DELAY for async requests. · 8478eaa1
      NeilBrown 提交于
      Currently asynchronous NFSv4 request will be retried with
      exponential timeout (from 1/10 to 15 seconds), but async
      requests will always use a 15second retry.
      
      Some "async" requests are really synchronous though.  The
      async mechanism is used to allow the request to continue if
      the requesting process is killed.
      In those cases, an exponential retry is appropriate.
      
      For example, if two different clients both open a file and
      get a READ delegation, and one client then unlinks the file
      (while still holding an open file descriptor), that unlink
      will used the "silly-rename" handling which is async.
      The first rename will result in NFS4ERR_DELAY while the
      delegation is reclaimed from the other client.  The rename
      will not be retried for 15 seconds, causing an unlink to take
      15 seconds rather than 100msec.
      
      This patch only added exponential timeout for async unlink and
      async rename.  Other async calls, such as 'close' are sometimes
      waited for so they might benefit from exponential timeout too.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      8478eaa1
  26. 13 9月, 2014 1 次提交