1. 02 2月, 2010 1 次提交
  2. 04 2月, 2010 1 次提交
  3. 26 1月, 2010 2 次提交
    • D
      xfs: Use delay write promotion for dquot flushing · 7d6a7bde
      Dave Chinner 提交于
      xfs_qm_dqflock_pushbuf_wait() does a very similar trick to item
      pushing used to do to flush out delayed write dquot buffers. Change
      it to use the new promotion method rather than an async flush.
      
      Also, xfs_qm_dqflock_pushbuf_wait() can return without the flush lock
      held, yet the callers make the assumption that after this call the
      flush lock is held. Always return with the flush lock held.
      Signed-off-by: NDave Chinner <david@fromorbit.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      7d6a7bde
    • D
      xfs: Sort delayed write buffers before dispatch · 089716aa
      Dave Chinner 提交于
      Currently when the xfsbufd writes delayed write buffers, it pushes
      them to disk in the order they come off the delayed write list. If
      there are lots of buffers ѕpread widely over the disk, this results
      in overwhelming the elevator sort queues in the block layer and we
      end up losing the posibility of merging adjacent buffers to minimise
      the number of IOs.
      
      Use the new generic list_sort function to sort the delwri dispatch
      queue before issue to ensure that the buffers are pushed in the most
      friendly order possible to the lower layers.
      Signed-off-by: NDave Chinner <david@fromorbit.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      089716aa
  4. 02 2月, 2010 1 次提交
    • D
      xfs: Don't issue buffer IO direct from AIL push V2 · d808f617
      Dave Chinner 提交于
      All buffers logged into the AIL are marked as delayed write.
      When the AIL needs to push the buffer out, it issues an async write of the
      buffer. This means that IO patterns are dependent on the order of
      buffers in the AIL.
      
      Instead of flushing the buffer, promote the buffer in the delayed
      write list so that the next time the xfsbufd is run the buffer will
      be flushed by the xfsbufd. Return the state to the xfsaild that the
      buffer was promoted so that the xfsaild knows that it needs to cause
      the xfsbufd to run to flush the buffers that were promoted.
      
      Using the xfsbufd for issuing the IO allows us to dispatch all
      buffer IO from the one queue. This means that we can make much more
      enlightened decisions on what order to flush buffers to disk as
      we don't have multiple places issuing IO. Optimisations to xfsbufd
      will be in a future patch.
      
      Version 2
      - kill XFS_ITEM_FLUSHING as it is now unused.
      Signed-off-by: NDave Chinner <david@fromorbit.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      d808f617
  5. 06 2月, 2010 2 次提交
    • D
      xfs: Use delayed write for inodes rather than async V2 · c854363e
      Dave Chinner 提交于
      We currently do background inode flush asynchronously, resulting in
      inodes being written in whatever order the background writeback
      issues them. Not only that, there are also blocking and non-blocking
      asynchronous inode flushes, depending on where the flush comes from.
      
      This patch completely removes asynchronous inode writeback. It
      removes all the strange writeback modes and replaces them with
      either a synchronous flush or a non-blocking delayed write flush.
      That is, inode flushes will only issue IO directly if they are
      synchronous, and background flushing may do nothing if the operation
      would block (e.g. on a pinned inode or buffer lock).
      
      Delayed write flushes will now result in the inode buffer sitting in
      the delwri queue of the buffer cache to be flushed by either an AIL
      push or by the xfsbufd timing out the buffer. This will allow
      accumulation of dirty inode buffers in memory and allow optimisation
      of inode cluster writeback at the xfsbufd level where we have much
      greater queue depths than the block layer elevators. We will also
      get adjacent inode cluster buffer IO merging for free when a later
      patch in the series allows sorting of the delayed write buffers
      before dispatch.
      
      This effectively means that any inode that is written back by
      background writeback will be seen as flush locked during AIL
      pushing, and will result in the buffers being pushed from there.
      This writeback path is currently non-optimal, but the next patch
      in the series will fix that problem.
      
      A side effect of this delayed write mechanism is that background
      inode reclaim will no longer directly flush inodes, nor can it wait
      on the flush lock. The result is that inode reclaim must leave the
      inode in the reclaimable state until it is clean. Hence attempts to
      reclaim a dirty inode in the background will simply skip the inode
      until it is clean and this allows other mechanisms (i.e. xfsbufd) to
      do more optimal writeback of the dirty buffers. As a result, the
      inode reclaim code has been rewritten so that it no longer relies on
      the ambiguous return values of xfs_iflush() to determine whether it
      is safe to reclaim an inode.
      
      Portions of this patch are derived from patches by Christoph
      Hellwig.
      
      Version 2:
      - cleanup reclaim code as suggested by Christoph
      - log background reclaim inode flush errors
      - just pass sync flags to xfs_iflush
      Signed-off-by: NDave Chinner <david@fromorbit.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      c854363e
    • D
      xfs: Make inode reclaim states explicit · 777df5af
      Dave Chinner 提交于
      A.K.A.: don't rely on xfs_iflush() return value in reclaim
      
      We have gradually been moving checks out of the reclaim code because
      they are duplicated in xfs_iflush(). We've had a history of problems
      in this area, and many of them stem from the overloading of the
      return values from xfs_iflush() and interaction with inode flush
      locking to determine if the inode is safe to reclaim.
      
      With the desire to move to delayed write flushing of inodes and
      non-blocking inode tree reclaim walks, the overloading of the
      return value of xfs_iflush makes it very difficult to determine
      the correct thing to do next.
      
      This patch explicitly re-adds the checks to the inode reclaim code,
      removing the reliance on the return value of xfs_iflush() to
      determine what to do next. It also means that we can clearly
      document all the inode states that reclaim must handle and hence
      we can easily see that we handled all the necessary cases.
      
      This also removes the need for the xfs_inode_clean() check in
      xfs_iflush() as all callers now check this first (safely).
      Signed-off-by: NDave Chinner <david@fromorbit.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      777df5af
  6. 09 2月, 2010 1 次提交
  7. 26 1月, 2010 2 次提交
    • D
      xfs: turn off sign warnings · 388f1f0c
      Dave Chinner 提交于
      Because they cause warnings in static inline functions conditionally
      compiled into XFS from the VFS (e.g. fsnotify).
      Signed-off-by: NDave Chinner <david@fromorbit.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      388f1f0c
    • D
      xfs: don't hold onto reserved blocks on remount,ro · cbe132a8
      Dave Chinner 提交于
      If we hold onto reserved blocks when doing a remount,ro we end
      up writing the blocks used count to disk that includes the reserved
      blocks. Reserved blocks are not actually used, so this results in
      the values in the superblock being incorrect.
      
      Hence if we run xfs_check or xfs_repair -n while the filesystem is
      mounted remount,ro we end up with an inconsistent filesystem being
      reported. Also, running xfs_copy on the remount,ro filesystem will
      result in an inconsistent image being generated.
      
      To fix this, unreserve the blocks when doing the remount,ro, and
      reserved them again on remount,rw. This way a remount,ro filesystem
      will appear consistent on disk to all utilities.
      Signed-off-by: NDave Chinner <david@fromorbit.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      cbe132a8
  8. 22 1月, 2010 8 次提交
  9. 20 1月, 2010 10 次提交
  10. 16 1月, 2010 12 次提交