1. 06 9月, 2011 2 次提交
  2. 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
  3. 23 3月, 2011 3 次提交
  4. 15 3月, 2011 8 次提交
  5. 28 10月, 2010 7 次提交
  6. 03 8月, 2010 2 次提交
  7. 28 5月, 2010 1 次提交
  8. 22 5月, 2010 1 次提交
  9. 13 3月, 2010 2 次提交
  10. 06 3月, 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 3 次提交
  13. 23 10月, 2008 1 次提交
  14. 18 10月, 2008 4 次提交
  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 5月, 2008 1 次提交
  17. 07 2月, 2008 1 次提交