1. 10 1月, 2014 1 次提交
  2. 04 1月, 2012 1 次提交
  3. 06 9月, 2011 2 次提交
  4. 21 7月, 2011 1 次提交
    • J
      fs: push i_mutex and filemap_write_and_wait down into ->fsync() handlers · 02c24a82
      Josef Bacik 提交于
      Btrfs needs to be able to control how filemap_write_and_wait_range() is called
      in fsync to make it less of a painful operation, so push down taking i_mutex and
      the calling of filemap_write_and_wait() down into the ->fsync() handlers.  Some
      file systems can drop taking the i_mutex altogether it seems, like ext3 and
      ocfs2.  For correctness sake I just pushed everything down in all cases to make
      sure that we keep the current behavior the same for everybody, and then each
      individual fs maintainer can make up their mind about what to do from there.
      Thanks,
      Acked-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJosef Bacik <josef@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      02c24a82
  5. 15 3月, 2011 6 次提交
  6. 13 1月, 2011 1 次提交
    • A
      switch 9p · 98cd3fb0
      Al Viro 提交于
      here we actually *want* ->d_op for root; setting it allows to get rid
      of kludge in v9fs_kill_super() since now we have proper ->d_release()
      for root and don't need to call it manually.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      98cd3fb0
  7. 28 10月, 2010 3 次提交
    • V
      9p: Add datasync to client side TFSYNC/RFSYNC for dotl · b165d601
      Venkateswararao Jujjuri (JV) 提交于
      SYNOPSIS
          size[4] Tfsync tag[2] fid[4] datasync[4]
      
          size[4] Rfsync tag[2]
      
      DESCRIPTION
      
          The Tfsync transaction transfers ("flushes") all modified in-core data of
          file identified by fid to the disk device (or other  permanent  storage
          device)  where that  file  resides.
      
          If datasync flag is specified data will be fleshed but does not flush
          modified metadata unless  that  metadata  is  needed  in order to allow a
          subsequent data retrieval to be correctly handled.
      Signed-off-by: NVenkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      b165d601
    • M
      9p: Implement TLOCK · a099027c
      M. Mohan Kumar 提交于
      Synopsis
      
          size[4] TLock tag[2] fid[4] flock[n]
          size[4] RLock tag[2] status[1]
      
      Description
      
      Tlock is used to acquire/release byte range posix locks on a file
      identified by given fid. The reply contains status of the lock request
      
          flock structure:
              type[1] - Type of lock: F_RDLCK, F_WRLCK, F_UNLCK
              flags[4] - Flags could be either of
                P9_LOCK_FLAGS_BLOCK - Blocked lock request, if there is a
                  conflicting lock exists, wait for that lock to be released.
                P9_LOCK_FLAGS_RECLAIM - Reclaim lock request, used when client is
                  trying to reclaim a lock after a server restrart (due to crash)
              start[8] - Starting offset for lock
              length[8] - Number of bytes to lock
                If length is 0, lock all bytes starting at the location 'start'
                through to the end of file
              pid[4] - PID of the process that wants to take lock
              client_id[4] - Unique client id
      
              status[1] - Status of the lock request, can be
                P9_LOCK_SUCCESS(0), P9_LOCK_BLOCKED(1), P9_LOCK_ERROR(2) or
                P9_LOCK_GRACE(3)
                P9_LOCK_SUCCESS - Request was successful
                P9_LOCK_BLOCKED - A conflicting lock is held by another process
                P9_LOCK_ERROR - Error while processing the lock request
                P9_LOCK_GRACE - Server is in grace period, it can't accept new lock
                  requests in this period (except locks with
                  P9_LOCK_FLAGS_RECLAIM flag set)
      Signed-off-by: NM. Mohan Kumar <mohan@in.ibm.com>
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NVenkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      a099027c
    • A
      fs/9p: Implement setting posix acl · 22d8dcdf
      Aneesh Kumar K.V 提交于
      This patch also update mode bits, as a normal file system.
      I am not sure wether we should do that, considering that
      a setxattr on the server will again update the ACL/mode value
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NVenkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      22d8dcdf
  8. 10 8月, 2010 1 次提交
  9. 03 8月, 2010 1 次提交
    • S
      9p: getattr client implementation for 9P2000.L protocol. · f0853122
      Sripathi Kodi 提交于
              SYNOPSIS
      
                    size[4] Tgetattr tag[2] fid[4] request_mask[8]
      
                    size[4] Rgetattr tag[2] lstat[n]
      
                 DESCRIPTION
      
                    The getattr transaction inquires about the file identified by fid.
                    request_mask is a bit mask that specifies which fields of the
                    stat structure is the client interested in.
      
                    The reply will contain a machine-independent directory entry,
                    laid out as follows:
      
                       st_result_mask[8]
                          Bit mask that indicates which fields in the stat structure
                          have been populated by the server
      
                       qid.type[1]
                          the type of the file (directory, etc.), represented as a bit
                          vector corresponding to the high 8 bits of the file's mode
                          word.
      
                       qid.vers[4]
                          version number for given path
      
                       qid.path[8]
                          the file server's unique identification for the file
      
                       st_mode[4]
                          Permission and flags
      
                       st_uid[4]
                          User id of owner
      
                       st_gid[4]
                          Group ID of owner
      
                       st_nlink[8]
                          Number of hard links
      
                       st_rdev[8]
                          Device ID (if special file)
      
                       st_size[8]
                          Size, in bytes
      
                       st_blksize[8]
                          Block size for file system IO
      
                       st_blocks[8]
                          Number of file system blocks allocated
      
                       st_atime_sec[8]
                          Time of last access, seconds
      
                       st_atime_nsec[8]
                          Time of last access, nanoseconds
      
                       st_mtime_sec[8]
                          Time of last modification, seconds
      
                       st_mtime_nsec[8]
                          Time of last modification, nanoseconds
      
                       st_ctime_sec[8]
                          Time of last status change, seconds
      
                       st_ctime_nsec[8]
                          Time of last status change, nanoseconds
      
                       st_btime_sec[8]
                          Time of creation (birth) of file, seconds
      
                       st_btime_nsec[8]
                          Time of creation (birth) of file, nanoseconds
      
                       st_gen[8]
                          Inode generation
      
                       st_data_version[8]
                          Data version number
      
                    request_mask and result_mask bit masks contain the following bits
                       #define P9_STATS_MODE          0x00000001ULL
                       #define P9_STATS_NLINK         0x00000002ULL
                       #define P9_STATS_UID           0x00000004ULL
                       #define P9_STATS_GID           0x00000008ULL
                       #define P9_STATS_RDEV          0x00000010ULL
                       #define P9_STATS_ATIME         0x00000020ULL
                       #define P9_STATS_MTIME         0x00000040ULL
                       #define P9_STATS_CTIME         0x00000080ULL
                       #define P9_STATS_INO           0x00000100ULL
                       #define P9_STATS_SIZE          0x00000200ULL
                       #define P9_STATS_BLOCKS        0x00000400ULL
      
                       #define P9_STATS_BTIME         0x00000800ULL
                       #define P9_STATS_GEN           0x00001000ULL
                       #define P9_STATS_DATA_VERSION  0x00002000ULL
      
                       #define P9_STATS_BASIC         0x000007ffULL
                       #define P9_STATS_ALL           0x00003fffULL
      
              This patch implements the client side of getattr implementation for
              9P2000.L. It introduces a new structure p9_stat_dotl for getting
              Linux stat information along with QID. The data layout is similar to
              stat structure in Linux user space with the following major
              differences:
      
              inode (st_ino) is not part of data. Instead qid is.
      
              device (st_dev) is not part of data because this doesn't make sense
              on the client.
      
              All time variables are 64 bit wide on the wire. The kernel seems to use
              32 bit variables for these variables. However, some of the architectures
              have used 64 bit variables and glibc exposes 64 bit variables to user
              space on some architectures. Hence to be on the safer side we have made
              these 64 bit in the protocol. Refer to the comments in
              include/asm-generic/stat.h
      
              There are some additional fields: st_btime_sec, st_btime_nsec, st_gen,
              st_data_version apart from the bitmask, st_result_mask. The bit mask
              is filled by the server to indicate which stat fields have been
              populated by the server. Currently there is no clean way for the
              server to obtain these additional fields, so it sends back just the
              basic fields.
      Signed-off-by: NSripathi Kodi <sripathik@in.ibm.com>
      Signed-off-by: NEric Van Hensbegren <ericvh@gmail.com>
      f0853122
  10. 22 5月, 2010 1 次提交
  11. 09 2月, 2010 1 次提交
    • M
      9p: Include fsync support for 9p client · 7a4439c4
      M. Mohan Kumar 提交于
      Implement the fsync in the client side by marking stat field values to 'don't touch' so that server may 
      interpret it as a request to guarantee that the contents of the associated file are committed to stable 
      storage before the Rwstat message is returned.
      
      Without this patch, calling fsync on a 9p file results in "Invalid argument" error. Please check the attached 
      C program.
      
      Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> 
      Signed-off-by: M. Mohan Kumar <mohan@in.ibm.com> 
      Acked-by: NVenkateswararao Jujjuri (JV) <jvrao@linux.vnet.ibm.com>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      
      7a4439c4
  12. 24 9月, 2009 1 次提交
    • A
      9p: Add fscache support to 9p · 60e78d2c
      Abhishek Kulkarni 提交于
      This patch adds a persistent, read-only caching facility for
      9p clients using the FS-Cache caching backend.
      
      When the fscache facility is enabled, each inode is associated
      with a corresponding vcookie which is an index into the FS-Cache
      indexing tree. The FS-Cache indexing tree is indexed at 3 levels:
      - session object associated with each mount.
      - inode/vcookie
      - actual data (pages)
      
      A cache tag is chosen randomly for each session. These tags can
      be read off /sys/fs/9p/caches and can be passed as a mount-time
      parameter to re-attach to the specified caching session.
      Signed-off-by: NAbhishek Kulkarni <adkulkar@umail.iu.edu>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      60e78d2c
  13. 28 3月, 2009 1 次提交
  14. 18 10月, 2008 2 次提交
  15. 03 7月, 2008 1 次提交
    • E
      9p: fix O_APPEND in legacy mode · 2e4bef41
      Eric Van Hensbergen 提交于
      The legacy protocol's open operation doesn't handle an append operation
      (it is expected that the client take care of it).  We were incorrectly
      passing the extended protocol's flag through even in legacy mode.  This
      was reported in bugzilla report #10689.  This patch fixes the problem
      by disallowing extended protocol open modes from being passed in legacy
      mode and implemented append functionality on the client side by adding
      a seek after the open.
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      2e4bef41
  16. 15 7月, 2007 1 次提交
  17. 27 3月, 2007 1 次提交
  18. 19 2月, 2007 1 次提交
    • E
      9p: implement optional loose read cache · e03abc0c
      Eric Van Hensbergen 提交于
      While cacheing is generally frowned upon in the 9p world, it has its
      place -- particularly in situations where the remote file system is
      exclusive and/or read-only.  The vacfs views of venti content addressable
      store are a real-world instance of such a situation.  To facilitate higher
      performance for these workloads (and eventually use the fscache patches),
      we have enabled a "loose" cache mode which does not attempt to maintain
      any form of consistency on the page-cache or dcache.  This results in over
      two orders of magnitude performance improvement for cacheable block reads
      in the Bonnie benchmark.  The more aggressive use of the dcache also seems
      to improve metadata operational performance.
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      e03abc0c
  19. 29 6月, 2006 1 次提交
  20. 29 3月, 2006 1 次提交
  21. 26 3月, 2006 1 次提交
  22. 03 3月, 2006 1 次提交
  23. 19 1月, 2006 1 次提交
  24. 09 1月, 2006 1 次提交
  25. 10 9月, 2005 1 次提交