xfs
[Top] [All Lists]

[XFS updates] XFS development tree branch, master, updated. v2.6.38-1896

To: xfs@xxxxxxxxxxx
Subject: [XFS updates] XFS development tree branch, master, updated. v2.6.38-18963-g1316d4d
From: xfs@xxxxxxxxxxx
Date: Thu, 7 Jul 2011 10:35:00 -0500
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "XFS development tree".

The branch, master has been updated
  1316d4d xfs: unpin stale inodes directly in IOP_COMMITTED
      from  4a33821236f2ef3af0081e8a5eec1301cbed3125 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 1316d4da3f632d5843d5a446203e73067dc40f09
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Mon Jul 4 05:27:36 2011 +0000

    xfs: unpin stale inodes directly in IOP_COMMITTED
    
    When inodes are marked stale in a transaction, they are treated
    specially when the inode log item is being inserted into the AIL.
    It tries to avoid moving the log item forward in the AIL due to a
    race condition with the writing the underlying buffer back to disk.
    The was "fixed" in commit de25c18 ("xfs: avoid moving stale inodes
    in the AIL").
    
    To avoid moving the item forward, we return a LSN smaller than the
    commit_lsn of the completing transaction, thereby trying to trick
    the commit code into not moving the inode forward at all. I'm not
    sure this ever worked as intended - it assumes the inode is already
    in the AIL, but I don't think the returned LSN would have been small
    enough to prevent moving the inode. It appears that the reason it
    worked is that the lower LSN of the inodes meant they were inserted
    into the AIL and flushed before the inode buffer (which was moved to
    the commit_lsn of the transaction).
    
    The big problem is that with delayed logging, the returning of the
    different LSN means insertion takes the slow, non-bulk path.  Worse
    yet is that insertion is to a position -before- the commit_lsn so it
    is doing a AIL traversal on every insertion, and has to walk over
    all the items that have already been inserted into the AIL. It's
    expensive.
    
    To compound the matter further, with delayed logging inodes are
    likely to go from clean to stale in a single checkpoint, which means
    they aren't even in the AIL at all when we come across them at AIL
    insertion time. Hence these were all getting inserted into the AIL
    when they simply do not need to be as inodes marked XFS_ISTALE are
    never written back.
    
    Transactional/recovery integrity is maintained in this case by the
    other items in the unlink transaction that were modified (e.g. the
    AGI btree blocks) and committed in the same checkpoint.
    
    So to fix this, simply unpin the stale inodes directly in
    xfs_inode_item_committed() and return -1 to indicate that the AIL
    insertion code does not need to do any further processing of these
    inodes.
    
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxx>
    Signed-off-by: Alex Elder <aelder@xxxxxxx>

-----------------------------------------------------------------------

Summary of changes:
 fs/xfs/xfs_inode_item.c |   14 ++++++++------
 fs/xfs/xfs_trans.c      |    4 ++--
 2 files changed, 10 insertions(+), 8 deletions(-)


hooks/post-receive
-- 
XFS development tree

<Prev in Thread] Current Thread [Next in Thread>
  • [XFS updates] XFS development tree branch, master, updated. v2.6.38-18963-g1316d4d, xfs <=