xfs
[Top] [All Lists]

[XFS updates] XFS development tree branch, master, updated. v3.8-rc1-36-

To: xfs@xxxxxxxxxxx
Subject: [XFS updates] XFS development tree branch, master, updated. v3.8-rc1-36-gfa5566e
From: xfs@xxxxxxxxxxx
Date: Thu, 14 Feb 2013 17:29:15 -0600 (CST)
Delivered-to: xfs@xxxxxxxxxxx
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
  fa5566e xfs: remove log force from xfs_buf_trylock()
  5337fe9 xfs: recheck buffer pinned status after push trylock failure
  a1e16c2 xfs: limit speculative prealloc size on sparse files
      from  311f08acde635e4e5ccea9b9d8c856cc2e0ced95 (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 fa5566e4ffb918131a054413eb42075a77a41413
Author: Brian Foster <bfoster@xxxxxxxxxx>
Date:   Mon Feb 11 10:08:22 2013 -0500

    xfs: remove log force from xfs_buf_trylock()
    
    The trylock log force invoked via xfs_buf_item_push() can attempt
    to acquire xa_lock, thus leading to a recursion bug when called
    with xa_lock held.
    
    This log force was originally added to xfs_buf_trylock() to address
    xfsaild stalls due to pinned and stale buffers. Since the addition
    of this behavior, the log item pushing code had been reworked to
    detect and track pinned items to inform xfsaild to issue a log
    force itself when necessary. As such, the log force on trylock
    failure is redundant and safe to remove.
    
    Signed-off-by: Brian Foster <bfoster@xxxxxxxxxx>
    Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>

commit 5337fe9b108d602c483fe9d62ffef9227acf3a74
Author: Brian Foster <bfoster@xxxxxxxxxx>
Date:   Mon Feb 11 10:08:21 2013 -0500

    xfs: recheck buffer pinned status after push trylock failure
    
    The buffer pinned check and trylock sequence in xfs_buf_item_push()
    can race with an active transaction on marking the buffer pinned.
    This can result in the buffer becoming pinned and stale after the
    initial check and the trylock failure, but before the check in
    xfs_buf_trylock() that issues a log force. If the log force is
    issued from this context, a spinlock recursion occurs on xa_lock.
    
    Prepare xfs_buf_item_push() to handle the race by detecting a
    pinned buffer after the trylock failure so xfsaild issues a log
    force from a safe context. This, along with various previous fixes,
    renders the log force in xfs_buf_trylock() redundant.
    
    Signed-off-by: Brian Foster <bfoster@xxxxxxxxxx>
    Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>

commit a1e16c26660b301cc8423185924cf1b0b16ea92b
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Mon Feb 11 16:05:01 2013 +1100

    xfs: limit speculative prealloc size on sparse files
    
    Speculative preallocation based on the current file size works well
    for contiguous files, but is sub-optimal for sparse files where the
    EOF preallocation can fill holes and result in large amounts of
    zeros being written when it is not necessary.
    
    The algorithm is modified to prevent EOF speculative preallocation
    from triggering larger allocations on IO patterns of
    truncate--to-zero-seek-write-seek-write-....  which results in
    non-sparse files for large files. This, unfortunately, is the way cp
    now behaves when copying sparse files and so needs to be fixed.
    
    What this code does is that it looks at the existing extent adjacent
    to the current EOF and if it determines that it is a hole we disable
    speculative preallocation altogether. To avoid the next write from
    doing a large prealloc, it takes the size of subsequent
    preallocations from the current size of the existing EOF extent.
    IOWs, if you leave a hole in the file, it resets preallocation
    behaviour to the same as if it was a zero size file.
    
    Example new behaviour:
    
    $ xfs_io -f -c "pwrite 0 31m" \
                -c "pwrite 33m 1m" \
                -c "pwrite 128m 1m" \
                -c "fiemap -v" /mnt/scratch/blah
    wrote 32505856/32505856 bytes at offset 0
    31 MiB, 7936 ops; 0.0000 sec (1.608 GiB/sec and 421432.7439 ops/sec)
    wrote 1048576/1048576 bytes at offset 34603008
    1 MiB, 256 ops; 0.0000 sec (1.462 GiB/sec and 383233.5329 ops/sec)
    wrote 1048576/1048576 bytes at offset 134217728
    1 MiB, 256 ops; 0.0000 sec (1.719 GiB/sec and 450704.2254 ops/sec)
    /mnt/scratch/blah:
     EXT: FILE-OFFSET      BLOCK-RANGE      TOTAL FLAGS
       0: [0..65535]:      96..65631        65536   0x0
       1: [65536..67583]:  hole              2048
       2: [67584..69631]:  67680..69727      2048   0x0
       3: [69632..262143]: hole             192512
       4: [262144..264191]: 262240..264287    2048   0x1
    
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Reviewed-by: Mark Tinguely <tinguely@xxxxxxx>
    Reviewed-by: Brian Foster <bfoster@xxxxxxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>

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

Summary of changes:
 fs/xfs/xfs_buf.c      |  2 --
 fs/xfs/xfs_buf_item.c | 12 +++++++-
 fs/xfs/xfs_iomap.c    | 77 ++++++++++++++++++++++++++++++++++++++++++++-------
 3 files changed, 78 insertions(+), 13 deletions(-)


hooks/post-receive
-- 
XFS development tree

<Prev in Thread] Current Thread [Next in Thread>
  • [XFS updates] XFS development tree branch, master, updated. v3.8-rc1-36-gfa5566e, xfs <=