1. 02 9月, 2009 1 次提交
    • C
      xfs: merge fsync and O_SYNC handling · 13e6d5cd
      Christoph Hellwig 提交于
      The guarantees for O_SYNC are exactly the same as the ones we need to
      make for an fsync call (and given that Linux O_SYNC is O_DSYNC the
      equivalent is fdadatasync, but we treat both the same in XFS), except
      with a range data writeout.  Jan Kara has started unifying these two
      path for filesystems using the generic helpers, and I've started to
      look at XFS.
      
      The actual transaction commited by xfs_fsync and xfs_write_sync_logforce
      has a different transaction number, but actually is exactly the same.
      We'll only use the fsync transaction going forward.  One major difference
      is that xfs_write_sync_logforce never issues a cache flush unless we
      commit a transaction causing that as a side-effect, which is an obvious
      bug in the O_SYNC handling.  Second all the locking and i_update_size
      vs i_update_core changes from 978b7237
      never made it to xfs_write_sync_logforce, so we add them back.
      
      To make xfs_fsync easily usable from the O_SYNC path, the filemap_fdatawait
      call is moved up to xfs_file_fsync, so that we don't wait on the whole
      file after we already waited for our portion in xfs_write.
      
      We'll also use a plain call to filemap_write_and_wait_range instead
      of the previous sync_page_rang which did it in two steps including
      an half-hearted inode write out that doesn't help us.
      
      Once we're done with this also remove the now useless i_update_size
      tracking.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NFelix Blyakher <felixb@sgi.com>
      Signed-off-by: NFelix Blyakher <felixb@sgi.com>
      13e6d5cd
  2. 10 6月, 2009 1 次提交
  3. 11 12月, 2008 1 次提交
  4. 13 8月, 2008 1 次提交
  5. 18 4月, 2008 1 次提交
    • D
      [XFS] Sanitise xfs_log_force error checking. · b911ca04
      David Chinner 提交于
      xfs_log_force() is declared to return an error, but we almost never check
      it. We don't need to check it in most cases; if there's a log I/O error
      then we'll be shutting down the filesystem anyway and that means we'll
      catch the error somewhere else.
      
      However, on certain calls we should be returning an error - sync
      transactions, fsync, sync writes, etc. so this isn't a pure black and
      white distinction. Hence make xfs_log_force() a void function that issues
      a warning to the syslog on error, and call _xfs_log_force() in all the
      places where we actually care about the error status returned.
      
      SGI-PV: 980084
      SGI-Modid: xfs-linux-melb:xfs-kern:30832a
      Signed-off-by: NDavid Chinner <dgc@sgi.com>
      Signed-off-by: NNiv Sardi <xaiki@sgi.com>
      Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>
      b911ca04
  6. 16 10月, 2007 1 次提交
  7. 08 5月, 2007 1 次提交
  8. 10 2月, 2007 1 次提交
  9. 20 6月, 2006 1 次提交
  10. 19 6月, 2006 1 次提交
  11. 09 6月, 2006 1 次提交
  12. 11 1月, 2006 1 次提交
  13. 02 11月, 2005 3 次提交
  14. 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