[XFS updates] XFS development tree branch, for-next, updated. for-linus-v3.10-rc1-2-14681-g211d022

[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-next has been updated
  211d022 xfs: Avoid pathological backwards allocation
      from  f722406faae2d073cc1d01063d1123c35425939e (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 211d022c43cac3aecbe967fcaf9b10156bfa63ad
Author: Jan Kara <jack at suse.cz>
Date:   Thu Apr 11 22:09:56 2013 +0200

    xfs: Avoid pathological backwards allocation
    
    Writing a large file using direct IO in 16 MB chunks sometimes results
    in a pathological allocation pattern where 16 MB chunks of large free
    extent are allocated to a file in a reversed order. So extents of a file
    look for example as:
    
     ext logical physical expected length flags
       0        0        13          4550656
       1  4550656 188136807   4550668 12562432
       2 17113088 200699240 200699238 622592
       3 17735680 182046055 201321831   4096
       4 17739776 182041959 182050150   4096
       5 17743872 182037863 182046054   4096
       6 17747968 182033767 182041958   4096
       7 17752064 182029671 182037862   4096
    ...
    6757 45400064 154381644 154389835   4096
    6758 45404160 154377548 154385739   4096
    6759 45408256 252951571 154381643  73728 eof
    
    This happens because XFS_ALLOCTYPE_THIS_BNO allocation fails (the last
    extent in the file cannot be further extended) so we fall back to
    XFS_ALLOCTYPE_NEAR_BNO allocation which picks end of a large free
    extent as the best place to continue the file. Since the chunk at the
    end of the free extent again cannot be further extended, this behavior
    repeats until the whole free extent is consumed in a reversed order.
    
    For data allocations this backward allocation isn't beneficial so make
    xfs_alloc_compute_diff() pick start of a free extent instead of its end
    for them. That avoids the backward allocation pattern.
    
    See thread at http://oss.sgi.com/archives/xfs/2013-03/msg00144.html for
    more details about the reproduction case and why this solution was
    chosen.
    
    Based on idea by Dave Chinner <dchinner at redhat.com>.
    
    CC: Dave Chinner <dchinner at redhat.com>
    Signed-off-by: Jan Kara <jack at suse.cz>
    Reviewed-by: Dave Chinner <dchinner at redhat.com>
    Reviewed-by: Mark Tinguely <tinguely at sgi.com>
    Signed-off-by: Ben Myers <bpm at sgi.com>

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

Summary of changes:
 fs/xfs/xfs_alloc.c | 24 ++++++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)


hooks/post-receive
-- 
XFS development tree