• 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
xfs_sync.c 20.9 KB