[XFS updates] XFS development tree branch, for-linus, updated. v2.6.33-9182-gf1d486a

[xfs at oss.sgi.com]

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
  f1d486a xfs: don't warn on EAGAIN in inode reclaim
  b6f8dd4 xfs: ensure that sync updates the log tail correctly
      from  dc57da3875f527b1cc195ea4ce5bd32e1e68433d (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 f1d486a3617a2f620b31224e4ace1496c4627e39
Author: Dave Chinner <dchinner at redhat.com>
Date:   Tue Apr 13 15:06:45 2010 +1000

    xfs: don't warn on EAGAIN in inode reclaim
    
    Any inode reclaim flush that returns EAGAIN will result in the inode
    reclaim being attempted again later. There is no need to issue a
    warning into the logs about this situation.
    
    Signed-off-by: Dave Chinner <dchinner at redhat.com>
    Reviewed-by: Alex Elder <aelder at sgi.com>
    Signed-off-by: Alex Elder <aelder at sgi.com>

commit b6f8dd49dbdbfa60a33bba3d4b766fe341109b4b
Author: Dave Chinner <dchinner at redhat.com>
Date:   Tue Apr 13 15:06:44 2010 +1000

    xfs: ensure that sync updates the log tail correctly
    
    Updates to the VFS layer removed an extra ->sync_fs call into the
    filesystem during the sync process (from the quota code).
    Unfortunately the sync code was unknowingly relying on this call to
    make sure metadata buffers were flushed via a xfs_buftarg_flush()
    call to move the tail of the log forward in memory before the final
    transactions of the sync process were issued.
    
    As a result, the old code would write a very recent log tail value
    to the log by the end of the sync process, and so a subsequent crash
    would leave nothing for log recovery to do. Hence in qa test 182,
    log recovery only replayed a small handle for inode fsync
    transactions in this case.
    
    However, with the removal of the extra ->sync_fs call, the log tail
    was now not moved forward with the inode fsync transactions near the
    end of the sync procese the first (and only) buftarg flush occurred
    after these transactions went to disk. The result is that log
    recovery now sees a large number of transactions for metadata that
    is already on disk.
    
    This usually isn't a problem, but when the transactions include
    inode chunk allocation, the inode create transactions and all
    subsequent changes are replayed as we cannt rely on what is on disk
    is valid. As a result, if the inode was written and contains
    unlogged changes, the unlogged changes are lost, thereby violating
    sync semantics.
    
    The fix is to always issue a transaction after the buftarg flush
    occurs is the log iѕ not idle or covered. This results in a dummy
    transaction being written that contains the up-to-date log tail
    value, which will be very recent. Indeed, it will be at least as
    recent as the old code would have left on disk, so log recovery
    will behave exactly as it used to in this situation.
    
    Signed-off-by: Dave Chinner <dchinner at redhat.com>
    Reviewed-by: Christoph Hellwig <hch at lst.de>
    Signed-off-by: Alex Elder <aelder at sgi.com>

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

Summary of changes:
 fs/xfs/linux-2.6/xfs_sync.c |    4 ++--
 fs/xfs/xfs_log.c            |   38 ++++++++++++++++++++++++++------------
 2 files changed, 28 insertions(+), 14 deletions(-)


hooks/post-receive
-- 
XFS development tree