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
233eebb xfs: correctly decrement the extent buffer index in xfs_bmap_del_extent
87bef18 xfs: check for valid indices in xfs_iext_get_ext and xfs_iext_idx_to_irec
ab1908a xfs: fix up asserts in xfs_iflush_fork
f1c63b7 xfs: do not do pointer arithmetic on extent records
00239ac xfs: do not use unchecked extent indices in xfs_bunmapi
5690f92 xfs: do not use unchecked extent indices in xfs_bmapi
2f2b322 xfs: do not use unchecked extent indices in xfs_bmap_add_extent_*
ec90c55 xfs: remove if_lastex
5489327 xfs: remove the unused XFS_BMAPI_RSVBLOCKS flag
55a7bc5 xfs: do not discard alloc btree blocks
e84661a xfs: add online discard support
from bf59170a66bc3eaf3ee513aa6ce9774aa2ab5188 (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 233eebb9a96f956c541c0c9094fd321894bd93a7
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Wed May 11 15:04:05 2011 +0000
xfs: correctly decrement the extent buffer index in xfs_bmap_del_extent
The code in xfs_bmap_del_extent does not correctly decrement the
extent buffer index when deleting a whole extent. Most of the time
this gets caught by checks in xfs_bmapi that work around it and
decrement it manually and thus wasn't noticed so far.
Based on an earlier patch from Lachlan McIlroy.
Signed-off-by: Christoph Hellwig <hch@xxxxxx>
Reviewed-by: Lachlan McIlroy <lmcilroy@xxxxxxxxxx>
Signed-off-by: Alex Elder <aelder@xxxxxxx>
commit 87bef1812d337beadfb1099e7361fd41264eb88e
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Wed May 11 15:04:11 2011 +0000
xfs: check for valid indices in xfs_iext_get_ext and xfs_iext_idx_to_irec
Based on an earlier patch from Lachlan McIlroy.
Signed-off-by: Christoph Hellwig <hch@xxxxxx>
Reviewed-by: Lachlan McIlroy <lmcilroy@xxxxxxxxxx>
Signed-off-by: Alex Elder <aelder@xxxxxxx>
commit ab1908a5bb21a8eebf16e5d92d087fd9413cf67d
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Wed May 11 15:04:10 2011 +0000
xfs: fix up asserts in xfs_iflush_fork
Remove asserts in xfs_iflush_fork that would call xfs_iext_get_ext
with a potentially invalid extent buffer index.
Based on an earlier patch from Lachlan McIlroy.
Signed-off-by: Christoph Hellwig <hch@xxxxxx>
Reviewed-by: Lachlan McIlroy <lmcilroy@xxxxxxxxxx>
Signed-off-by: Alex Elder <aelder@xxxxxxx>
commit f1c63b73cf60dc4800cde5ce7fd9466c419e5e36
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Wed May 11 15:04:09 2011 +0000
xfs: do not do pointer arithmetic on extent records
We need to call xfs_iext_get_ext for the previous extent to get a
valid pointer, and can't just do pointer arithmetics as they might
be in different pages.
Signed-off-by: Christoph Hellwig <hch@xxxxxx>
Reviewed-by: Lachlan McIlroy <lmcilroy@xxxxxxxxxx>
Signed-off-by: Alex Elder <aelder@xxxxxxx>
commit 00239acf36d3bba8e7c0609e6c473d6e408a2135
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Wed May 11 15:04:08 2011 +0000
xfs: do not use unchecked extent indices in xfs_bunmapi
Make sure to only call xfs_iext_get_ext after we've validate the
extent index when moving on to the next index in xfs_bunmapi. Also
remove the old workaround for too large indices that has been
superceeded by the proper fix in xfs_bmap_del_extent.
Based on an earlier patch from Lachlan McIlroy.
Signed-off-by: Christoph Hellwig <hch@xxxxxx>
Reviewed-by: Lachlan McIlroy <lmcilroy@xxxxxxxxxx>
Signed-off-by: Alex Elder <aelder@xxxxxxx>
commit 5690f92199956c0f2a2d9f718b5031e1300a1de1
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Wed May 11 15:04:07 2011 +0000
xfs: do not use unchecked extent indices in xfs_bmapi
Make sure to only call xfs_iext_get_ext after we've validate the
extent index when moving on to the next index in xfs_bmapi.
Based on an earlier patch from Lachlan McIlroy.
Signed-off-by: Christoph Hellwig <hch@xxxxxx>
Reviewed-by: Lachlan McIlroy <lmcilroy@xxxxxxxxxx>
Signed-off-by: Alex Elder <aelder@xxxxxxx>
commit 2f2b3220b0566692da14e06ea5fc0d697a78dc7c
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Wed May 11 15:04:06 2011 +0000
xfs: do not use unchecked extent indices in xfs_bmap_add_extent_*
Make sure to only call xfs_iext_get_ext after we've validate the
extent index in the various xfs_bmap_add_extent_* helpers.
Based on an earlier patch from Lachlan McIlroy.
Signed-off-by: Christoph Hellwig <hch@xxxxxx>
Reviewed-by: Lachlan McIlroy <lmcilroy@xxxxxxxxxx>
Signed-off-by: Alex Elder <aelder@xxxxxxx>
commit ec90c5563413ba6d29607397c54958d49c3461a3
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Mon May 23 08:52:53 2011 +0000
xfs: remove if_lastex
The if_lastex field in struct xfs_ifork is only used as a temporary
index during xfs_bmapi and xfs_bunmapi. Instead of using the inode
fork to store it keep it local in the callchain. Fortunately this
is very easy as we already pass a stack copy of it down the whole
chain which can simplify be changed to be passed by reference.
Signed-off-by: Christoph Hellwig <hch@xxxxxx>
Signed-off-by: Alex Elder <aelder@xxxxxxx>
commit 548932739b16e623601f6d7dfb31a1fe28cda050
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Wed May 11 15:04:03 2011 +0000
xfs: remove the unused XFS_BMAPI_RSVBLOCKS flag
The XFS_BMAPI_RSVBLOCKS is unused, and as far as I can see has
always been. Remove it to simplify the bmapi implementation and
conserve stack space.
Signed-off-by: Christoph Hellwig <hch@xxxxxx>
Signed-off-by: Alex Elder <aelder@xxxxxxx>
commit 55a7bc5a30ff2d30d8a34fea2af9fc601b32e61a
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Wed May 4 18:55:15 2011 +0000
xfs: do not discard alloc btree blocks
Blocks for the allocation btree are allocated from and released to
the AGFL, and thus frequently reused. Even worse we do not have an
easy way to avoid using an AGFL block when it is discarded due to
the simple FILO list of free blocks, and thus can frequently stall
on blocks that are currently undergoing a discard.
Add a flag to the busy extent tracking structure to skip the discard
for allocation btree blocks. In normal operation these blocks are
reused frequently enough that there is no need to discard them
anyway, but if they spill over to the allocation btree as part of a
balance we "leak" blocks that we would otherwise discard. We could
fix this by adding another flag and keeping these block in the
rbtree even after they aren't busy any more so that we could discard
them when they migrate out of the AGFL. Given that this would cause
significant overhead I don't think it's worthwile for now.
Signed-off-by: Christoph Hellwig <hch@xxxxxx>
Signed-off-by: Alex Elder <aelder@xxxxxxx>
commit e84661aa84e2e003738563f65155d4f12dc474e7
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Fri May 20 13:45:32 2011 +0000
xfs: add online discard support
Now that we have reliably tracking of deleted extents in a
transaction we can easily implement "online" discard support
which calls blkdev_issue_discard once a transaction commits.
The actual discard is a two stage operation as we first have
to mark the busy extent as not available for reuse before we
can start the actual discard. Note that we don't bother
supporting discard for the non-delaylog mode.
Signed-off-by: Christoph Hellwig <hch@xxxxxx>
Signed-off-by: Alex Elder <aelder@xxxxxxx>
-----------------------------------------------------------------------
Summary of changes:
fs/xfs/linux-2.6/xfs_discard.c | 29 ++
fs/xfs/linux-2.6/xfs_discard.h | 2 +
fs/xfs/linux-2.6/xfs_super.c | 18 ++-
fs/xfs/xfs_ag.h | 3 +
fs/xfs/xfs_alloc.c | 35 +++-
fs/xfs/xfs_alloc.h | 5 +-
fs/xfs/xfs_alloc_btree.c | 3 +-
fs/xfs/xfs_bmap.c | 549 +++++++++++++++++++---------------------
fs/xfs/xfs_bmap.h | 2 -
fs/xfs/xfs_inode.c | 15 +-
fs/xfs/xfs_inode.h | 1 -
fs/xfs/xfs_log_cil.c | 13 +-
fs/xfs/xfs_mount.h | 1 +
fs/xfs/xfs_trans.c | 2 +-
14 files changed, 360 insertions(+), 318 deletions(-)
hooks/post-receive
--
XFS development tree
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
