[Top] [All Lists]

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

To: xfs@xxxxxxxxxxx
Subject: [XFS updates] XFS development tree branch, for-linus, updated. v3.2-rc1-11-g9f9c19e
From: xfs@xxxxxxxxxxx
Date: Wed, 7 Dec 2011 16:43:00 -0600
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
  9f9c19e xfs: fix the logspace waiting algorithm
  c29f7d4 xfs: fix nfs export of 64-bit inodes numbers on 32-bit kernels
  a99ebf4 xfs: fix allocation length overflow in xfs_bmapi_write()
      from  4c393a6059f8442a70512a48ce4639b882b6f6ad (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 9f9c19ec1a59422c7687b11847ed3408128aa0d6
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date:   Mon Nov 28 08:17:36 2011 +0000

    xfs: fix the logspace waiting algorithm
    Apply the scheme used in log_regrant_write_log_space to wake up any other
    threads waiting for log space before the newly added one to
    log_regrant_write_log_space as well, and factor the code into readable
    helpers.  For each of the queues we have add two helpers:
     - one to try to wake up all waiting threads.  This helper will also be
       usable by xfs_log_move_tail once we remove the current opportunistic
       wakeups in it.
     - one to sleep on t_wait until enough log space is available, loosely
       modelled after Linux waitqueues.
    And use them to reimplement the guts of log_regrant_write_log_space and
    log_regrant_write_log_space.  These two function now use one and the same
    algorithm for waiting on log space instead of subtly different ones before,
    with an option to completely unify them in the near future.
    Also move the filesystem shutdown handling to the common caller given
    that we had to touch it anyway.
    Based on hard debugging and an earlier patch from
    Chandra Seetharaman <sekharan@xxxxxxxxxx>.
    Signed-off-by: Christoph Hellwig <hch@xxxxxx>
    Reviewed-by: Chandra Seetharaman <sekharan@xxxxxxxxxx>
    Tested-by: Chandra Seetharaman <sekharan@xxxxxxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>

commit c29f7d457ac63311feb11928a866efd2fe153d74
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date:   Wed Nov 30 08:58:18 2011 +0000

    xfs: fix nfs export of 64-bit inodes numbers on 32-bit kernels
    The i_ino field in the VFS inode is of type unsigned long and thus can't
    hold the full 64-bit inode number on 32-bit kernels.  We have the full
    inode number in the XFS inode, so use that one for nfs exports.  Note
    that I've also switched the 32-bit file handles types to it, just to make
    the code more consistent and copy & paste errors less likely to happen.
    Reported-by: Guoquan Yang <ygq51@xxxxxxxxxxx>
    Reported-by: Hank Peng <pengxihan@xxxxxxxxx>
    Signed-off-by: Christoph Hellwig <hch@xxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>

commit a99ebf43f49f4499ab0e2a8a9132ad6ed6ba2409
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Thu Dec 1 11:24:20 2011 +0000

    xfs: fix allocation length overflow in xfs_bmapi_write()
    When testing the new xfstests --large-fs option that does very large
    file preallocations, this assert was tripped deep in
    XFS: Assertion failed: args->minlen <= args->maxlen, file: 
fs/xfs/xfs_alloc.c, line: 2239
    The allocation was trying to allocate a zero length extent because
    the lower 32 bits of the allocation length was zero. The remaining
    length of the allocation to be done was an exact multiple of 2^32 -
    the first case I saw was at 496TB remaining to be allocated.
    This turns out to be an overflow when converting the allocation
    length (a 64 bit quantity) into the extent length to allocate (a 32
    bit quantity), and it requires the length to be allocated an exact
    multiple of 2^32 blocks to trip the assert.
    Fix it by limiting the extent lenth to allocate to MAXEXTLEN.
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxx>


Summary of changes:
 fs/xfs/xfs_bmap.c   |   20 +++-
 fs/xfs/xfs_export.c |    8 +-
 fs/xfs/xfs_log.c    |  348 +++++++++++++++++++++++++--------------------------
 fs/xfs/xfs_trace.h  |   12 +--
 4 files changed, 200 insertions(+), 188 deletions(-)

XFS development tree

<Prev in Thread] Current Thread [Next in Thread>
  • [XFS updates] XFS development tree branch, for-linus, updated. v3.2-rc1-11-g9f9c19e, xfs <=