[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-xfs
Subject:    [XFS updates] XFS development tree branch, for-linus,
From:       xfs () oss ! sgi ! com
Date:       2011-12-29 16:29:40
Message-ID: 201112291629.pBTGTeVF017911 () oss ! sgi ! com
[Download RAW message or body]

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, for-linus has been updated
  be4f1ac xfs: log all dirty inodes in xfs_fs_sync_fs
  0b8fd30 xfs: log the inode in ->write_inode calls for kupdate
      from  9f9c19ec1a59422c7687b11847ed3408128aa0d6 (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 be4f1ac828776bbc7868a68b465cd8eedb733cfd
Author: Christoph Hellwig <hch@infradead.org>
Date:   Tue Dec 20 20:08:41 2011 +0000

    xfs: log all dirty inodes in xfs_fs_sync_fs
    
    Since Linux 2.6.36 the writeback code has introduces various measures for
    live lock prevention during sync().  Unfortunately some of these are
    actively harmful for the XFS model, where the inode gets marked dirty for
    metadata from the data I/O handler.
    
    The older_than_this checks that are now more strictly enforced since
    
        writeback: avoid livelocking WB_SYNC_ALL writeback
    
    by only calling into __writeback_inodes_sb and thus only sampling the
    current cut off time once.  But on a slow enough devices the previous
    asynchronous sync pass might not have fully completed yet, and thus XFS
    might mark metadata dirty only after that sampling of the cut off time for
    the blocking pass already happened.  I have not myself reproduced this
    myself on a real system, but by introducing artificial delay into the
    XFS I/O completion workqueues it can be reproduced easily.
    
    Fix this by iterating over all XFS inodes in ->sync_fs and log all that
    are dirty.  This might log inode that only got redirtied after the
    previous pass, but given how cheap delayed logging of inodes is it
    isn't a major concern for performance.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>
    Tested-by: Mark Tinguely <tinguely@sgi.com>
    Reviewed-by: Mark Tinguely <tinguely@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>

commit 0b8fd3033c308e4088760aa1d38ce77197b4e074
Author: Christoph Hellwig <hch@infradead.org>
Date:   Sun Dec 18 15:49:55 2011 +0000

    xfs: log the inode in ->write_inode calls for kupdate
    
    If the writeback code writes back an inode because it has expired we currently
    use the non-blockin ->write_inode path.  This means any inode that is pinned
    is skipped.  With delayed logging and a workload that has very little log
    traffic otherwise it is very likely that an inode that gets constantly
    written to is always pinned, and thus we keep refusing to write it.  The VM
    writeback code at that point redirties it and doesn't try to write it again
    for another 30 seconds.  This means under certain scenarious time based
    metadata writeback never happens.
    
    Fix this by calling into xfs_log_inode for kupdate in addition to data
    integrity syncs, and thus transfer the inode to the log ASAP.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>
    Tested-by: Mark Tinguely <tinguely@sgi.com>
    Reviewed-by: Mark Tinguely <tinguely@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>

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

Summary of changes:
 fs/xfs/xfs_super.c |   30 +++++-------------------------
 fs/xfs/xfs_sync.c  |   36 ++++++++++++++++++++++++++++++++++++
 fs/xfs/xfs_sync.h  |    2 ++
 3 files changed, 43 insertions(+), 25 deletions(-)


hooks/post-receive
-- 
XFS development tree

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
[prev in list] [next in list] [prev in thread] [next in thread]