1. 09 10月, 2009 1 次提交
    • C
      xfs: implement ->dirty_inode to fix timestamp handling · f9581b14
      Christoph Hellwig 提交于
      This is picking up on Felix's repost of Dave's patch to implement a
      .dirty_inode method.  We really need this notification because
      the VFS keeps writing directly into the inode structure instead
      of going through methods to update this state.  In addition to
      the long-known atime issue we now also have a caller in VM code
      that updates c/mtime that way for shared writeable mmaps.  And
      I found another one that no one has noticed in practice in the FIFO
      code.
      
      So implement ->dirty_inode to set i_update_core whenever the
      inode gets externally dirtied, and switch the c/mtime handling to
      the same scheme we already use for atime (always picking up
      the value from the Linux inode).
      
      Note that this patch also removes the xfs_synchronize_atime call
      in xfs_reclaim it was superflous as we already synchronize the time
      when writing the inode via the log (xfs_inode_item_format) or the
      normal buffers (xfs_iflush_int).
      
      In addition also remove the I_CLEAR check before copying the Linux
      timestamps - now that we always have the Linux inode available
      we can always use the timestamps in it.
      
      Also switch to just using file_update_time for regular reads/writes -
      that will get us all optimization done to it for free and make
      sure we notice early when it breaks.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NFelix Blyakher <felixb@sgi.com>
      Reviewed-by: NAlex Elder <aelder@sgi.com>
      Signed-off-by: NAlex Elder <aelder@sgi.com>
      f9581b14
  2. 02 9月, 2009 2 次提交
    • C
      xfs: simplify xfs_trans_iget · aa72a5cf
      Christoph Hellwig 提交于
      xfs_trans_iget is a wrapper for xfs_iget that adds the inode to the
      transaction after it is read.  Except when the inode already is in the
      inode cache, in which case it returns the existing locked inode with
      increment lock recursion counts.
      
      Now, no one in the tree every decrements these lock recursion counts,
      so any user of this gets a potential double unlock when both the original
      owner of the inode and the xfs_trans_iget caller unlock it.  When looking
      back in a git bisect in the historic XFS tree there was only one place
      that decremented these counts, xfs_trans_iput.  Introduced in commit
      ca25df7a840f426eb566d52667b6950b92bb84b5 by Adam Sweeney in 1993,
      and removed in commit 19f899a3ab155ff6a49c0c79b06f2f61059afaf3 by
      Steve Lord in 2003.  And as long as it didn't slip through git bisects
      cracks never actually used in that time frame.
      
      A quick audit of the callers of xfs_trans_iget shows that no caller
      really relies on this behaviour fortunately - xfs_ialloc allows this
      inode from disk so it must not be there before, and all the RT allocator
      routines only every add each RT bitmap inode once.
      
      In addition to removing lots of code and reducing the size of the inode
      item this patch also avoids the double inode cache lookup in each
      create/mkdir/mknod transaction.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NAlex Elder <aelder@sgi.com>
      Signed-off-by: NFelix Blyakher <felixb@sgi.com>
      aa72a5cf
    • 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
  3. 01 12月, 2008 3 次提交
  4. 30 10月, 2008 3 次提交
  5. 13 8月, 2008 1 次提交
  6. 28 7月, 2008 1 次提交
  7. 29 4月, 2008 1 次提交
    • C
      [XFS] shrink mrlock_t · 579aa9ca
      Christoph Hellwig 提交于
      The writer field is not needed for non_DEBU builds so remove it. While
      we're at i also clean up the interface for is locked asserts to go through
      and xfs_iget.c helper with an interface like the xfs_ilock routines to
      isolated the XFS codebase from mrlock internals. That way we can kill
      mrlock_t entirely once rw_semaphores grow an islocked facility. Also
      remove unused flags to the ilock family of functions.
      
      SGI-PV: 976035
      SGI-Modid: xfs-linux-melb:xfs-kern:30902a
      Signed-off-by: NChristoph Hellwig <hch@infradead.org>
      Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>
      579aa9ca
  8. 18 4月, 2008 1 次提交
  9. 10 4月, 2008 1 次提交
  10. 07 2月, 2008 2 次提交
  11. 10 2月, 2007 1 次提交
    • D
      [XFS] Keep stack usage down for 4k stacks by using noinline. · 7989cb8e
      David Chinner 提交于
      gcc-4.1 and more recent aggressively inline static functions which
      increases XFS stack usage by ~15% in critical paths. Prevent this from
      occurring by adding noinline to the STATIC definition.
      
      Also uninline some functions that are too large to be inlined and were
      causing problems with CONFIG_FORCED_INLINING=y.
      
      Finally, clean up all the different users of inline, __inline and
      __inline__ and put them under one STATIC_INLINE macro. For debug kernels
      the STATIC_INLINE macro uninlines those functions.
      
      SGI-PV: 957159
      SGI-Modid: xfs-linux-melb:xfs-kern:27585a
      Signed-off-by: NDavid Chinner <dgc@sgi.com>
      Signed-off-by: NDavid Chatterton <chatz@sgi.com>
      Signed-off-by: NTim Shimmin <tes@sgi.com>
      7989cb8e
  12. 28 9月, 2006 1 次提交
  13. 20 6月, 2006 1 次提交
  14. 19 6月, 2006 1 次提交
  15. 09 6月, 2006 1 次提交
  16. 29 3月, 2006 1 次提交
  17. 12 1月, 2006 1 次提交
  18. 11 1月, 2006 1 次提交
  19. 02 11月, 2005 2 次提交
  20. 08 9月, 2005 1 次提交
  21. 02 9月, 2005 1 次提交
  22. 21 6月, 2005 1 次提交
  23. 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