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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
  5a5881c xfs: add lots of attribute trace points
  d97d32e xfs: Fix oops on IO error during xlog_recover_process_iunlinks()
  a66d636 xfs: fix fstrim offset calculations
  3948659 xfs: Account log unmount transaction correctly
  5132ba8 xfs: don't cache inodes read through bulkstat
  f616137 xfs: trace xfs_name strings correctly
  c999a22 xfs: introduce an allocation workqueue
  1a1d772 xfs: Fix open flag handling in open_by_handle code
  5575acc xfs: fix deadlock in xfs_rtfree_extent
  1c2ccc6 fs: xfs: fix section mismatch in linux-next
      from  f074211f6041305b645669464343d504f4e6a290 (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 5a5881cdeec2c019b5c9a307800218ee029f7f61
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Thu Mar 22 05:15:13 2012 +0000

    xfs: add lots of attribute trace points
    
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>

commit d97d32edcd732110758799ae60af725e5110b3dc
Author: Jan Kara <jack@xxxxxxx>
Date:   Thu Mar 15 09:34:02 2012 +0000

    xfs: Fix oops on IO error during xlog_recover_process_iunlinks()
    
    When an IO error happens during inode deletion run from
    xlog_recover_process_iunlinks() filesystem gets shutdown. Thus any subsequent
    attempt to read buffers fails. Code in xlog_recover_process_iunlinks() does not
    count with the fact that read of a buffer which was read a while ago can
    really fail which results in the oops on
      agi = XFS_BUF_TO_AGI(agibp);
    
    Fix the problem by cleaning up the buffer handling in
    xlog_recover_process_iunlinks() as suggested by Dave Chinner. We release buffer
    lock but keep buffer reference to AG buffer. That is enough for buffer to stay
    pinned in memory and we don't have to call xfs_read_agi() all the time.
    
    CC: stable@xxxxxxxxxx
    Signed-off-by: Jan Kara <jack@xxxxxxx>
    Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>

commit a66d636385d621e98a915233250356c394a437de
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Thu Mar 22 05:15:12 2012 +0000

    xfs: fix fstrim offset calculations
    
    xfs_ioc_fstrim() doesn't treat the incoming offset and length
    correctly. It treats them as a filesystem block address, rather than
    a disk address. This is wrong because the range passed in is a
    linear representation, while the filesystem block address notation
    is a sparse representation. Hence we cannot convert the range direct
    to filesystem block units and then use that for calculating the
    range to trim.
    
    While this sounds dangerous, the problem is limited to calculating
    what AGs need to be trimmed. The code that calcuates the actual
    ranges to trim gets the right result (i.e. only ever discards free
    space), even though it uses the wrong ranges to limit what is
    trimmed. Hence this is not a bug that endangers user data.
    
    Fix this by treating the range as a disk address range and use the
    appropriate functions to convert the range into the desired formats
    for calculations.
    
    Further, fix the first free extent lookup (the longest) to actually
    find the largest free extent. Currently this lookup uses a <=
    lookup, which results in finding the extent to the left of the
    largest because we can never get an exact match on the largest
    extent. This is due to the fact that while we know it's size, we
    don't know it's location and so the exact match fails and we move
    one record to the left to get the next largest extent. Instead, use
    a >= search so that the lookup returns the largest extent regardless
    of the fact we don't get an exact match on it.
    
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>

commit 3948659e30808fbaa7673bbe89de2ae9769e20a7
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Thu Mar 22 05:15:11 2012 +0000

    xfs: Account log unmount transaction correctly
    
    There have been a few reports of this warning appearing recently:
    
    XFS (dm-4): xlog_space_left: head behind tail
     tail_cycle = 129, tail_bytes = 20163072
     GH   cycle = 129, GH   bytes = 20162880
    
    The common cause appears to be lots of freeze and unfreeze cycles,
    and the output from the warnings indicates that we are leaking
    around 8 bytes of log space per freeze/unfreeze cycle.
    
    When we freeze the filesystem, we write an unmount record and that
    uses xlog_write directly - a special type of transaction,
    effectively. What it doesn't do, however, is correctly account for
    the log space it uses. The unmount record writes an 8 byte structure
    with a special magic number into the log, and the space this
    consumes is not accounted for in the log ticket tracking the
    operation. Hence we leak 8 bytes every unmount record that is
    written.
    
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>

commit 5132ba8f2b7705fb6b06fa6ad3d009233c816b67
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Thu Mar 22 05:15:10 2012 +0000

    xfs: don't cache inodes read through bulkstat
    
    When we read inodes via bulkstat, we generally only read them once
    and then throw them away - they never get used again. If we retain
    them in cache, then it simply causes the working set of inodes and
    other cached items to be reclaimed just so the inode cache can grow.
    
    Avoid this problem by marking inodes read by bulkstat not to be
    cached and check this flag in .drop_inode to determine whether the
    inode should be added to the VFS LRU or not. If the inode lookup
    hits an already cached inode, then don't set the flag. If the inode
    lookup hits an inode marked with no cache flag, remove the flag and
    allow it to be cached once the current reference goes away.
    
    Inodes marked as not cached will get cleaned up by the background
    inode reclaim or via memory pressure, so they will still generate
    some short term cache pressure. They will, however, be reclaimed
    much sooner and in preference to cache hot inodes.
    
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>

commit f616137519feb17b849894fcbe634a021d3fa7db
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date:   Tue Feb 28 11:01:40 2012 +0000

    xfs: trace xfs_name strings correctly
    
    Strings store in an xfs_name structure are often not NUL terminated,
    print them using the correct printf specifiers that make use of the
    string length store in the xfs_name structure.
    
    Reported-by: Brian Candler <B.Candler@xxxxxxxxx>
    Signed-off-by: Christoph Hellwig <hch@xxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>

commit c999a223c2f0d31c64ef7379814cea1378b2b800
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Thu Mar 22 05:15:07 2012 +0000

    xfs: introduce an allocation workqueue
    
    We currently have significant issues with the amount of stack that
    allocation in XFS uses, especially in the writeback path. We can
    easily consume 4k of stack between mapping the page, manipulating
    the bmap btree and allocating blocks from the free list. Not to
    mention btree block readahead and other functionality that issues IO
    in the allocation path.
    
    As a result, we can no longer fit allocation in the writeback path
    in the stack space provided on x86_64. To alleviate this problem,
    introduce an allocation workqueue and move all allocations to a
    seperate context. This can be easily added as an interposing layer
    into xfs_alloc_vextent(), which takes a single argument structure
    and does not return until the allocation is complete or has failed.
    
    To do this, add a work structure and a completion to the allocation
    args structure. This allows xfs_alloc_vextent to queue the args onto
    the workqueue and wait for it to be completed by the worker. This
    can be done completely transparently to the caller.
    
    The worker function needs to ensure that it sets and clears the
    PF_TRANS flag appropriately as it is being run in an active
    transaction context. Work can also be queued in a memory reclaim
    context, so a rescuer is needed for the workqueue.
    
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>

commit 1a1d772433d42aaff7315b3468fef5951604f5c6
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Thu Mar 22 05:15:06 2012 +0000

    xfs: Fix open flag handling in open_by_handle code
    
    Sparse identified some unsafe handling of open flags in the xfs open
    by handle ioctl code. Update the code to use the correct access
    macros to ensure that we handle the open flags correctly.
    
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxx>
    Reviewed-by: Mark Tinguely <tinguely@xxxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>

commit 5575acc7807595687288b3bbac15103f2a5462e1
Author: Kamal Dasu <kdasu.kdev@xxxxxxxxx>
Date:   Thu Feb 23 00:41:39 2012 +0000

    xfs: fix deadlock in xfs_rtfree_extent
    
    To fix the deadlock caused by repeatedly calling xfs_rtfree_extent
    
     - removed xfs_ilock() and xfs_trans_ijoin() from xfs_rtfree_extent(),
       instead added asserts that the inode is locked and has an inode_item
       attached to it.
     - in xfs_bunmapi() when dealing with an inode with the rt flag
       call xfs_ilock() and xfs_trans_ijoin() so that the
       reference count is bumped on the inode and attached it to the
       transaction before calling into xfs_bmap_del_extent, similar to
       what we do in xfs_bmap_rtalloc.
    
    Signed-off-by: Kamal Dasu <kdasu.kdev@xxxxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxxxxxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>

commit 1c2ccc66bcef992bec7bad6d52cade66d632d7fb
Author: Gerard Snitselaar <dev@xxxxxxxxxxxxxx>
Date:   Fri Mar 16 18:36:18 2012 +0000

    fs: xfs: fix section mismatch in linux-next
    
    xfs_qm_exit() is called in init_xfs_fs().
    
    Signed-off-by: Gerard Snitselaar <dev@xxxxxxxxxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>

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

Summary of changes:
 fs/xfs/xfs_alloc.c       |   36 ++++++++++++++++++++-
 fs/xfs/xfs_alloc.h       |   12 +++++++
 fs/xfs/xfs_attr.c        |   16 +++++++++
 fs/xfs/xfs_attr_leaf.c   |   40 +++++++++++++++++++++--
 fs/xfs/xfs_bmap.c        |    9 +++++
 fs/xfs/xfs_da_btree.c    |   32 +++++++++++++++++++
 fs/xfs/xfs_discard.c     |   61 ++++++++++++++++++++++-------------
 fs/xfs/xfs_dquot.c       |    2 +-
 fs/xfs/xfs_iget.c        |    8 +++-
 fs/xfs/xfs_inode.h       |    4 ++-
 fs/xfs/xfs_ioctl.c       |   14 +++-----
 fs/xfs/xfs_itable.c      |    3 +-
 fs/xfs/xfs_log.c         |    3 +-
 fs/xfs/xfs_log_recover.c |   33 ++++++-------------
 fs/xfs/xfs_rtalloc.c     |    9 ++---
 fs/xfs/xfs_super.c       |   33 +++++++++++++++++++
 fs/xfs/xfs_trace.h       |   78 +++++++++++++++++++++++++++++++++++++++++++---
 17 files changed, 317 insertions(+), 76 deletions(-)


hooks/post-receive
-- 
XFS development tree

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs


[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux