[XFS updates] XFS development tree branch, for-next, updated. v3.7-rc1-26-g69a58a4

[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-next has been updated
  69a58a4 xfs: report projid32bit feature in geometry call
  009507b xfs: fix reading of wrapped log data
  137fff0 xfs: fix buffer shudown reference count mismatch
  b6aff29 xfs: don't vmap inode cluster buffers during free
  4c05f9a xfs: invalidate allocbt blocks moved to the free list
      from  c99abb8f560798625323c7b21d5636259017825d (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 69a58a43f74eb2cb23d9bce2524dae33c289a40f
Author: Eric Sandeen <sandeen@xxxxxxxxxx>
Date:   Tue Oct 9 14:11:45 2012 -0500

    xfs: report projid32bit feature in geometry call
    
    When xfs gained the projid32bit feature, it was never added to
    the FSGEOMETRY ioctl feature flags, so it's not queryable without
    this patch.
    
    Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx>
    Reviewed-by: Carlos Maiolino <cmaiolino@xxxxxxxxxx>
    Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>

commit 009507b052fa391618eccf9e8c9f484407fd9018
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Fri Nov 2 11:38:44 2012 +1100

    xfs: fix reading of wrapped log data
    
    Commit 4439647 ("xfs: reset buffer pointers before freeing them") in
    3.0-rc1 introduced a regression when recovering log buffers that
    wrapped around the end of log. The second part of the log buffer at
    the start of the physical log was being read into the header buffer
    rather than the data buffer, and hence recovery was seeing garbage
    in the data buffer when it got to the region of the log buffer that
    was incorrectly read.
    
    Cc: <stable@xxxxxxxxxxxxxxx> # 3.0.x, 3.2.x, 3.4.x 3.6.x
    Reported-by: Torsten Kaiser <just.for.lkml@xxxxxxxxxxxxxx>
    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 137fff09b7924507871f8e6294dfe57b7a880332
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date:   Fri Nov 2 14:23:12 2012 +1100

    xfs: fix buffer shudown reference count mismatch
    
    When we shut down the filesystem, we have to unpin and free all the
    buffers currently active in the CIL. To do this we unpin and remove
    them in one operation as a result of a failed iclogbuf write. For
    buffers, we do this removal via a simultated IO completion of after
    marking the buffer stale.
    
    At the time we do this, we have two references to the buffer - the
    active LRU reference and the buf log item.  The LRU reference is
    removed by marking the buffer stale, and the active CIL reference is
    by the xfs_buf_iodone() callback that is run by
    xfs_buf_do_callbacks() during ioend processing (via the bp->b_iodone
    callback).
    
    However, ioend processing requires one more reference - that of the
    IO that it is completing. We don't have this reference, so we free
    the buffer prematurely and use it after it is freed. For buffers
    marked with XBF_ASYNC, this leads to assert failures in
    xfs_buf_rele() on debug kernels because the b_hold count is zero.
    
    Fix this by making sure we take the necessary IO reference before
    starting IO completion processing on the stale buffer, and set the
    XBF_ASYNC flag to ensure that IO completion processing removes all
    the active references from the buffer to ensure it is fully torn
    down.
    
    Cc: <stable@xxxxxxxxxxxxxxx>
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Reviewed-by: Mark Tinguely <tinguely@xxxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>

commit b6aff29f3af7437635ec3d66af9115bb17ba561f
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Fri Nov 2 11:38:42 2012 +1100

    xfs: don't vmap inode cluster buffers during free
    
    Inode buffers do not need to be mapped as inodes are read or written
    directly from/to the pages underlying the buffer. This fixes a
    regression introduced by commit 611c994 ("xfs: make XBF_MAPPED the
    default behaviour").
    
    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 4c05f9ad4d168098b7ce3ffa7098283f94811ed6
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Fri Nov 2 11:38:41 2012 +1100

    xfs: invalidate allocbt blocks moved to the free list
    
    When we free a block from the alloc btree tree, we move it to the
    freelist held in the AGFL and mark it busy in the busy extent tree.
    This typically happens when we merge btree blocks.
    
    Once the transaction is committed and checkpointed, the block can
    remain on the free list for an indefinite amount of time.  Now, this
    isn't the end of the world at this point - if the free list is
    shortened, the buffer is invalidated in the transaction that moves
    it back to free space. If the buffer is allocated as metadata from
    the free list, then all the modifications getted logged, and we have
    no issues, either. And if it gets allocated as userdata direct from
    the freelist, it gets invalidated and so will never get written.
    
    However, during the time it sits on the free list, pressure on the
    log can cause the AIL to be pushed and the buffer that covers the
    block gets pushed for write. IOWs, we end up writing a freed
    metadata block to disk. Again, this isn't the end of the world
    because we know from the above we are only writing to free space.
    
    The problem, however, is for validation callbacks. If the block was
    on old btree root block, then the level of the block is going to be
    higher than the current tree root, and so will fail validation.
    There may be other inconsistencies in the block as well, and
    currently we don't care because the block is in free space. Shutting
    down the filesystem because a freed block doesn't pass write
    validation, OTOH, is rather unfriendly.
    
    So, make sure we always invalidate buffers as they move from the
    free space trees to the free list so that we guarantee they never
    get written to disk while on the free list.
    
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxx>
    Reviewed-by: Phil White <pwhite@xxxxxxx>
    Reviewed-by: Mark Tinguely <tinguely@xxxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>

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

Summary of changes:
 fs/xfs/xfs_alloc_btree.c |    2 ++
 fs/xfs/xfs_buf_item.c    |   18 ++++++++++++++++++
 fs/xfs/xfs_fs.h          |    3 ++-
 fs/xfs/xfs_fsops.c       |    4 +++-
 fs/xfs/xfs_inode.c       |    3 ++-
 fs/xfs/xfs_log_recover.c |    2 +-
 6 files changed, 28 insertions(+), 4 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