1. 19 9月, 2006 1 次提交
  2. 09 9月, 2006 1 次提交
  3. 25 8月, 2006 1 次提交
    • T
      NFS: Fix issue with EIO on NFS read · 79558f36
      Trond Myklebust 提交于
      The problem is that we may be caching writes that would extend the file and
      create a hole in the region that we are reading. In this case, we need to
      detect the eof from the server, ensure that we zero out the pages that
      are part of the hole and mark them as up to date.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      (cherry picked from 856b603b01b99146918c093969b6cb1b1b0f1c01 commit)
      79558f36
  4. 04 8月, 2006 1 次提交
  5. 01 7月, 2006 1 次提交
  6. 28 6月, 2006 1 次提交
  7. 09 6月, 2006 3 次提交
    • D
      NFS: Split fs/nfs/inode.c · f7b422b1
      David Howells 提交于
      As fs/nfs/inode.c is rather large, heterogenous and unwieldy, the attached
      patch splits it up into a number of files:
      
       (*) fs/nfs/inode.c
      
           Strictly inode specific functions.
      
       (*) fs/nfs/super.c
      
           Superblock management functions for NFS and NFS4, normal access, clones
           and referrals.  The NFS4 superblock functions _could_ move out into a
           separate conditionally compiled file, but it's probably not worth it as
           there're so many common bits.
      
       (*) fs/nfs/namespace.c
      
           Some namespace-specific functions have been moved here.
      
       (*) fs/nfs/nfs4namespace.c
      
           NFS4-specific namespace functions (this could be merged into the previous
           file).  This file is conditionally compiled.
      
       (*) fs/nfs/internal.h
      
           Inter-file declarations, plus a few simple utility functions moved from
           fs/nfs/inode.c.
      
           Additionally, all the in-.c-file externs have been moved here, and those
           files they were moved from now includes this file.
      
      For the most part, the functions have not been changed, only some multiplexor
      functions have changed significantly.
      
      I've also:
      
       (*) Added some extra banner comments above some functions.
      
       (*) Rearranged the function order within the files to be more logical and
           better grouped (IMO), though someone may prefer a different order.
      
       (*) Reduced the number of #ifdefs in .c files.
      
       (*) Added missing __init and __exit directives.
      Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      f7b422b1
    • C
      NFS: Optimize allocation of nfs_read/write_data structures · 0d0b5cb3
      Chuck Lever 提交于
      Clean up use of page_array, and fix an off-by-one error noticed by Tom
      Talpey which causes kmalloc calls in cases where using the page_array
      is sufficient.
      
      Test plan:
      Normal client functional testing with r/wsize=32768.
      Signed-off-by: NChuck Lever <cel@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      0d0b5cb3
    • T
      NFS: Clean up and fix page zeroing when we have short reads · 1de3fc12
      Trond Myklebust 提交于
      The code that is supposed to zero the uninitialised partial pages when the
      server returns a short read is currently broken: it looks at the nfs_page
      wb_pgbase and wb_bytes fields instead of the equivalent nfs_read_data
      values when deciding where to start truncating the page.
      
      Also ensure that we are more careful about setting PG_uptodate
      before retrying a short read: the retry will change the nfs_read_data
      args.pgbase and args.count.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      1de3fc12
  8. 27 3月, 2006 1 次提交
  9. 21 3月, 2006 3 次提交
  10. 07 1月, 2006 2 次提交
    • C
      NFS: support large reads and writes on the wire · 40859d7e
      Chuck Lever 提交于
       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.
      
       Test-plan:
       Connectathon and iozone on mount point with wsize=rsize>32768 over TCP.
       Tests with NFS over UDP to verify the maximum RPC payload size cap.
      Signed-off-by: NChuck Lever <cel@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      40859d7e
    • T
      RPC: Clean up RPC task structure · 963d8fe5
      Trond Myklebust 提交于
       Shrink the RPC task structure. Instead of storing separate pointers
       for task->tk_exit and task->tk_release, put them in a structure.
      
       Also pass the user data pointer as a parameter instead of passing it via
       task->tk_calldata. This enables us to nest callbacks.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      963d8fe5
  11. 05 11月, 2005 1 次提交
    • T
      NFSv4: Fix problem with OPEN_DOWNGRADE · d530838b
      Trond Myklebust 提交于
       RFC 3530 states that for OPEN_DOWNGRADE "The share_access and share_deny
       bits specified must be exactly equal to the union of the share_access and
       share_deny bits specified for some subset of the OPENs in effect for
       current openowner on the current file.
      
       Setattr is currently violating the NFSv4 rules for OPEN_DOWNGRADE in that
       it may cause a downgrade from OPEN4_SHARE_ACCESS_BOTH to
       OPEN4_SHARE_ACCESS_WRITE despite the fact that there exists no open file
       with O_WRONLY access mode.
      
       Fix the problem by replacing nfs4_find_state() with a modified version of
       nfs_find_open_context().
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      d530838b
  12. 28 10月, 2005 1 次提交
  13. 23 9月, 2005 1 次提交
  14. 19 8月, 2005 2 次提交
  15. 23 6月, 2005 1 次提交
  16. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4