2005-04-17 06:20:36 +08:00
|
|
|
/*
|
2005-11-02 11:58:39 +08:00
|
|
|
* Copyright (c) 2000-2001,2005 Silicon Graphics, Inc.
|
|
|
|
* All Rights Reserved.
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
2005-11-02 11:58:39 +08:00
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License as
|
2005-04-17 06:20:36 +08:00
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*
|
2005-11-02 11:58:39 +08:00
|
|
|
* This program is distributed in the hope that it would be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
2005-11-02 11:58:39 +08:00
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write the Free Software Foundation,
|
|
|
|
* Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
#include "xfs.h"
|
2005-11-02 11:38:42 +08:00
|
|
|
#include "xfs_fs.h"
|
2014-11-28 11:25:04 +08:00
|
|
|
#include "xfs_format.h"
|
2013-10-23 07:50:10 +08:00
|
|
|
#include "xfs_log_format.h"
|
|
|
|
#include "xfs_trans_resv.h"
|
2005-04-17 06:20:36 +08:00
|
|
|
#include "xfs_mount.h"
|
2013-10-23 07:50:10 +08:00
|
|
|
#include "xfs_trans.h"
|
2005-04-17 06:20:36 +08:00
|
|
|
#include "xfs_trans_priv.h"
|
2013-10-23 07:50:10 +08:00
|
|
|
#include "xfs_buf_item.h"
|
2005-04-17 06:20:36 +08:00
|
|
|
#include "xfs_extfree_item.h"
|
2013-12-13 08:00:43 +08:00
|
|
|
#include "xfs_log.h"
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
|
|
|
kmem_zone_t *xfs_efi_zone;
|
|
|
|
kmem_zone_t *xfs_efd_zone;
|
|
|
|
|
2010-06-23 16:11:15 +08:00
|
|
|
static inline struct xfs_efi_log_item *EFI_ITEM(struct xfs_log_item *lip)
|
|
|
|
{
|
|
|
|
return container_of(lip, struct xfs_efi_log_item, efi_item);
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2005-06-21 13:41:19 +08:00
|
|
|
void
|
2010-06-23 16:11:15 +08:00
|
|
|
xfs_efi_item_free(
|
|
|
|
struct xfs_efi_log_item *efip)
|
2005-06-21 13:41:19 +08:00
|
|
|
{
|
2010-06-23 16:11:15 +08:00
|
|
|
if (efip->efi_format.efi_nextents > XFS_EFI_MAX_FAST_EXTENTS)
|
2008-05-19 14:31:57 +08:00
|
|
|
kmem_free(efip);
|
2010-06-23 16:11:15 +08:00
|
|
|
else
|
2005-06-21 13:41:19 +08:00
|
|
|
kmem_zone_free(xfs_efi_zone, efip);
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-12-20 08:59:49 +08:00
|
|
|
/*
|
|
|
|
* Freeing the efi requires that we remove it from the AIL if it has already
|
|
|
|
* been placed there. However, the EFI may not yet have been placed in the AIL
|
|
|
|
* when called by xfs_efi_release() from EFD processing due to the ordering of
|
xfs: don't free EFIs before the EFDs are committed
Filesystems are occasionally being shut down with this error:
xfs_trans_ail_delete_bulk: attempting to delete a log item that is
not in the AIL.
It was diagnosed to be related to the EFI/EFD commit order when the
EFI and EFD are in different checkpoints and the EFD is committed
before the EFI here:
http://oss.sgi.com/archives/xfs/2013-01/msg00082.html
The real problem is that a single bit cannot fully describe the
states that the EFI/EFD processing can be in. These completion
states are:
EFI EFI in AIL EFD Result
committed/unpinned Yes committed OK
committed/pinned No committed Shutdown
uncommitted No committed Shutdown
Note that the "result" field is what should happen, not what does
happen. The current logic is broken and handles the first two cases
correctly by luck. That is, the code will free the EFI if the
XFS_EFI_COMMITTED bit is *not* set, rather than if it is set. The
inverted logic "works" because if both EFI and EFD are committed,
then the first __xfs_efi_release() call clears the XFS_EFI_COMMITTED
bit, and the second frees the EFI item. Hence as long as
xfs_efi_item_committed() has been called, everything appears to be
fine.
It is the third case where the logic fails - where
xfs_efd_item_committed() is called before xfs_efi_item_committed(),
and that results in the EFI being freed before it has been
committed. That is the bug that triggered the shutdown, and hence
keeping track of whether the EFI has been committed or not is
insufficient to correctly order the EFI/EFD operations w.r.t. the
AIL.
What we really want is this: the EFI is always placed into the
AIL before the last reference goes away. The only way to guarantee
that is that the EFI is not freed until after it has been unpinned
*and* the EFD has been committed. That is, restructure the logic so
that the only case that can occur is the first case.
This can be done easily by replacing the XFS_EFI_COMMITTED with an
EFI reference count. The EFI is initialised with it's own count, and
that is not released until it is unpinned. However, there is a
complication to this method - the high level EFI/EFD code in
xfs_bmap_finish() does not hold direct references to the EFI
structure, and runs a transaction commit between the EFI and EFD
processing. Hence the EFI can be freed even before the EFD is
created using such a method.
Further, log recovery uses the AIL for tracking EFI/EFDs that need
to be recovered, but it uses the AIL *differently* to the EFI
transaction commit. Hence log recovery never pins or unpins EFIs, so
we can't drop the EFI reference count indirectly to free the EFI.
However, this doesn't prevent us from using a reference count here.
There is a 1:1 relationship between EFIs and EFDs, so when we
initialise the EFI we can take a reference count for the EFD as
well. This solves the xfs_bmap_finish() issue - the EFI will never
be freed until the EFD is processed. In terms of log recovery,
during the committing of the EFD we can look for the
XFS_EFI_RECOVERED bit being set and drop the EFI reference as well,
thereby ensuring everything works correctly there as well.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2013-04-03 11:09:21 +08:00
|
|
|
* committed vs unpin operations in bulk insert operations. Hence the reference
|
|
|
|
* count to ensure only the last caller frees the EFI.
|
2010-12-20 08:59:49 +08:00
|
|
|
*/
|
|
|
|
STATIC void
|
|
|
|
__xfs_efi_release(
|
|
|
|
struct xfs_efi_log_item *efip)
|
|
|
|
{
|
|
|
|
struct xfs_ail *ailp = efip->efi_item.li_ailp;
|
|
|
|
|
xfs: don't free EFIs before the EFDs are committed
Filesystems are occasionally being shut down with this error:
xfs_trans_ail_delete_bulk: attempting to delete a log item that is
not in the AIL.
It was diagnosed to be related to the EFI/EFD commit order when the
EFI and EFD are in different checkpoints and the EFD is committed
before the EFI here:
http://oss.sgi.com/archives/xfs/2013-01/msg00082.html
The real problem is that a single bit cannot fully describe the
states that the EFI/EFD processing can be in. These completion
states are:
EFI EFI in AIL EFD Result
committed/unpinned Yes committed OK
committed/pinned No committed Shutdown
uncommitted No committed Shutdown
Note that the "result" field is what should happen, not what does
happen. The current logic is broken and handles the first two cases
correctly by luck. That is, the code will free the EFI if the
XFS_EFI_COMMITTED bit is *not* set, rather than if it is set. The
inverted logic "works" because if both EFI and EFD are committed,
then the first __xfs_efi_release() call clears the XFS_EFI_COMMITTED
bit, and the second frees the EFI item. Hence as long as
xfs_efi_item_committed() has been called, everything appears to be
fine.
It is the third case where the logic fails - where
xfs_efd_item_committed() is called before xfs_efi_item_committed(),
and that results in the EFI being freed before it has been
committed. That is the bug that triggered the shutdown, and hence
keeping track of whether the EFI has been committed or not is
insufficient to correctly order the EFI/EFD operations w.r.t. the
AIL.
What we really want is this: the EFI is always placed into the
AIL before the last reference goes away. The only way to guarantee
that is that the EFI is not freed until after it has been unpinned
*and* the EFD has been committed. That is, restructure the logic so
that the only case that can occur is the first case.
This can be done easily by replacing the XFS_EFI_COMMITTED with an
EFI reference count. The EFI is initialised with it's own count, and
that is not released until it is unpinned. However, there is a
complication to this method - the high level EFI/EFD code in
xfs_bmap_finish() does not hold direct references to the EFI
structure, and runs a transaction commit between the EFI and EFD
processing. Hence the EFI can be freed even before the EFD is
created using such a method.
Further, log recovery uses the AIL for tracking EFI/EFDs that need
to be recovered, but it uses the AIL *differently* to the EFI
transaction commit. Hence log recovery never pins or unpins EFIs, so
we can't drop the EFI reference count indirectly to free the EFI.
However, this doesn't prevent us from using a reference count here.
There is a 1:1 relationship between EFIs and EFDs, so when we
initialise the EFI we can take a reference count for the EFD as
well. This solves the xfs_bmap_finish() issue - the EFI will never
be freed until the EFD is processed. In terms of log recovery,
during the committing of the EFD we can look for the
XFS_EFI_RECOVERED bit being set and drop the EFI reference as well,
thereby ensuring everything works correctly there as well.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2013-04-03 11:09:21 +08:00
|
|
|
if (atomic_dec_and_test(&efip->efi_refcount)) {
|
2010-12-20 08:59:49 +08:00
|
|
|
spin_lock(&ailp->xa_lock);
|
|
|
|
/* xfs_trans_ail_delete() drops the AIL lock. */
|
2012-04-23 13:58:41 +08:00
|
|
|
xfs_trans_ail_delete(ailp, &efip->efi_item,
|
|
|
|
SHUTDOWN_LOG_IO_ERROR);
|
2010-12-20 08:59:49 +08:00
|
|
|
xfs_efi_item_free(efip);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* This returns the number of iovecs needed to log the given efi item.
|
|
|
|
* We only need 1 iovec for an efi item. It just logs the efi_log_format
|
|
|
|
* structure.
|
|
|
|
*/
|
2013-08-12 18:50:04 +08:00
|
|
|
static inline int
|
|
|
|
xfs_efi_item_sizeof(
|
|
|
|
struct xfs_efi_log_item *efip)
|
|
|
|
{
|
|
|
|
return sizeof(struct xfs_efi_log_format) +
|
|
|
|
(efip->efi_format.efi_nextents - 1) * sizeof(xfs_extent_t);
|
|
|
|
}
|
|
|
|
|
|
|
|
STATIC void
|
2010-06-23 16:11:15 +08:00
|
|
|
xfs_efi_item_size(
|
2013-08-12 18:50:04 +08:00
|
|
|
struct xfs_log_item *lip,
|
|
|
|
int *nvecs,
|
|
|
|
int *nbytes)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2013-08-12 18:50:04 +08:00
|
|
|
*nvecs += 1;
|
|
|
|
*nbytes += xfs_efi_item_sizeof(EFI_ITEM(lip));
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is called to fill in the vector of log iovecs for the
|
|
|
|
* given efi log item. We use only 1 iovec, and we point that
|
|
|
|
* at the efi_log_format structure embedded in the efi item.
|
|
|
|
* It is at this point that we assert that all of the extent
|
|
|
|
* slots in the efi item have been filled.
|
|
|
|
*/
|
|
|
|
STATIC void
|
2010-06-23 16:11:15 +08:00
|
|
|
xfs_efi_item_format(
|
|
|
|
struct xfs_log_item *lip,
|
2013-12-13 08:34:02 +08:00
|
|
|
struct xfs_log_vec *lv)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2010-06-23 16:11:15 +08:00
|
|
|
struct xfs_efi_log_item *efip = EFI_ITEM(lip);
|
2013-12-13 08:34:02 +08:00
|
|
|
struct xfs_log_iovec *vecp = NULL;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-12-20 08:59:49 +08:00
|
|
|
ASSERT(atomic_read(&efip->efi_next_extent) ==
|
|
|
|
efip->efi_format.efi_nextents);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
efip->efi_format.efi_type = XFS_LI_EFI;
|
|
|
|
efip->efi_format.efi_size = 1;
|
|
|
|
|
2013-12-13 08:34:02 +08:00
|
|
|
xlog_copy_iovec(lv, &vecp, XLOG_REG_TYPE_EFI_FORMAT,
|
2013-12-13 08:00:43 +08:00
|
|
|
&efip->efi_format,
|
|
|
|
xfs_efi_item_sizeof(efip));
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Pinning has no meaning for an efi item, so just return.
|
|
|
|
*/
|
|
|
|
STATIC void
|
2010-06-23 16:11:15 +08:00
|
|
|
xfs_efi_item_pin(
|
|
|
|
struct xfs_log_item *lip)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2010-12-20 08:57:24 +08:00
|
|
|
* While EFIs cannot really be pinned, the unpin operation is the last place at
|
|
|
|
* which the EFI is manipulated during a transaction. If we are being asked to
|
|
|
|
* remove the EFI it's because the transaction has been cancelled and by
|
|
|
|
* definition that means the EFI cannot be in the AIL so remove it from the
|
xfs: don't free EFIs before the EFDs are committed
Filesystems are occasionally being shut down with this error:
xfs_trans_ail_delete_bulk: attempting to delete a log item that is
not in the AIL.
It was diagnosed to be related to the EFI/EFD commit order when the
EFI and EFD are in different checkpoints and the EFD is committed
before the EFI here:
http://oss.sgi.com/archives/xfs/2013-01/msg00082.html
The real problem is that a single bit cannot fully describe the
states that the EFI/EFD processing can be in. These completion
states are:
EFI EFI in AIL EFD Result
committed/unpinned Yes committed OK
committed/pinned No committed Shutdown
uncommitted No committed Shutdown
Note that the "result" field is what should happen, not what does
happen. The current logic is broken and handles the first two cases
correctly by luck. That is, the code will free the EFI if the
XFS_EFI_COMMITTED bit is *not* set, rather than if it is set. The
inverted logic "works" because if both EFI and EFD are committed,
then the first __xfs_efi_release() call clears the XFS_EFI_COMMITTED
bit, and the second frees the EFI item. Hence as long as
xfs_efi_item_committed() has been called, everything appears to be
fine.
It is the third case where the logic fails - where
xfs_efd_item_committed() is called before xfs_efi_item_committed(),
and that results in the EFI being freed before it has been
committed. That is the bug that triggered the shutdown, and hence
keeping track of whether the EFI has been committed or not is
insufficient to correctly order the EFI/EFD operations w.r.t. the
AIL.
What we really want is this: the EFI is always placed into the
AIL before the last reference goes away. The only way to guarantee
that is that the EFI is not freed until after it has been unpinned
*and* the EFD has been committed. That is, restructure the logic so
that the only case that can occur is the first case.
This can be done easily by replacing the XFS_EFI_COMMITTED with an
EFI reference count. The EFI is initialised with it's own count, and
that is not released until it is unpinned. However, there is a
complication to this method - the high level EFI/EFD code in
xfs_bmap_finish() does not hold direct references to the EFI
structure, and runs a transaction commit between the EFI and EFD
processing. Hence the EFI can be freed even before the EFD is
created using such a method.
Further, log recovery uses the AIL for tracking EFI/EFDs that need
to be recovered, but it uses the AIL *differently* to the EFI
transaction commit. Hence log recovery never pins or unpins EFIs, so
we can't drop the EFI reference count indirectly to free the EFI.
However, this doesn't prevent us from using a reference count here.
There is a 1:1 relationship between EFIs and EFDs, so when we
initialise the EFI we can take a reference count for the EFD as
well. This solves the xfs_bmap_finish() issue - the EFI will never
be freed until the EFD is processed. In terms of log recovery,
during the committing of the EFD we can look for the
XFS_EFI_RECOVERED bit being set and drop the EFI reference as well,
thereby ensuring everything works correctly there as well.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2013-04-03 11:09:21 +08:00
|
|
|
* transaction and free it. Otherwise coordinate with xfs_efi_release()
|
|
|
|
* to determine who gets to free the EFI.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
STATIC void
|
2010-06-23 16:11:15 +08:00
|
|
|
xfs_efi_item_unpin(
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
int remove)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2010-06-23 16:11:15 +08:00
|
|
|
struct xfs_efi_log_item *efip = EFI_ITEM(lip);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-12-20 08:57:24 +08:00
|
|
|
if (remove) {
|
|
|
|
ASSERT(!(lip->li_flags & XFS_LI_IN_AIL));
|
2011-01-27 09:13:35 +08:00
|
|
|
if (lip->li_desc)
|
|
|
|
xfs_trans_del_item(lip);
|
2005-06-21 13:41:19 +08:00
|
|
|
xfs_efi_item_free(efip);
|
2010-12-20 08:59:49 +08:00
|
|
|
return;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2010-12-20 08:59:49 +08:00
|
|
|
__xfs_efi_release(efip);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 13:58:39 +08:00
|
|
|
* Efi items have no locking or pushing. However, since EFIs are pulled from
|
|
|
|
* the AIL when their corresponding EFDs are committed to disk, their situation
|
|
|
|
* is very similar to being pinned. Return XFS_ITEM_PINNED so that the caller
|
|
|
|
* will eventually flush the log. This should help in getting the EFI out of
|
|
|
|
* the AIL.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
STATIC uint
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 13:58:39 +08:00
|
|
|
xfs_efi_item_push(
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
struct list_head *buffer_list)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
return XFS_ITEM_PINNED;
|
|
|
|
}
|
|
|
|
|
|
|
|
STATIC void
|
2010-06-23 16:11:15 +08:00
|
|
|
xfs_efi_item_unlock(
|
|
|
|
struct xfs_log_item *lip)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2010-06-23 16:11:15 +08:00
|
|
|
if (lip->li_flags & XFS_LI_ABORTED)
|
|
|
|
xfs_efi_item_free(EFI_ITEM(lip));
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2010-12-20 08:59:49 +08:00
|
|
|
* The EFI is logged only once and cannot be moved in the log, so simply return
|
xfs: don't free EFIs before the EFDs are committed
Filesystems are occasionally being shut down with this error:
xfs_trans_ail_delete_bulk: attempting to delete a log item that is
not in the AIL.
It was diagnosed to be related to the EFI/EFD commit order when the
EFI and EFD are in different checkpoints and the EFD is committed
before the EFI here:
http://oss.sgi.com/archives/xfs/2013-01/msg00082.html
The real problem is that a single bit cannot fully describe the
states that the EFI/EFD processing can be in. These completion
states are:
EFI EFI in AIL EFD Result
committed/unpinned Yes committed OK
committed/pinned No committed Shutdown
uncommitted No committed Shutdown
Note that the "result" field is what should happen, not what does
happen. The current logic is broken and handles the first two cases
correctly by luck. That is, the code will free the EFI if the
XFS_EFI_COMMITTED bit is *not* set, rather than if it is set. The
inverted logic "works" because if both EFI and EFD are committed,
then the first __xfs_efi_release() call clears the XFS_EFI_COMMITTED
bit, and the second frees the EFI item. Hence as long as
xfs_efi_item_committed() has been called, everything appears to be
fine.
It is the third case where the logic fails - where
xfs_efd_item_committed() is called before xfs_efi_item_committed(),
and that results in the EFI being freed before it has been
committed. That is the bug that triggered the shutdown, and hence
keeping track of whether the EFI has been committed or not is
insufficient to correctly order the EFI/EFD operations w.r.t. the
AIL.
What we really want is this: the EFI is always placed into the
AIL before the last reference goes away. The only way to guarantee
that is that the EFI is not freed until after it has been unpinned
*and* the EFD has been committed. That is, restructure the logic so
that the only case that can occur is the first case.
This can be done easily by replacing the XFS_EFI_COMMITTED with an
EFI reference count. The EFI is initialised with it's own count, and
that is not released until it is unpinned. However, there is a
complication to this method - the high level EFI/EFD code in
xfs_bmap_finish() does not hold direct references to the EFI
structure, and runs a transaction commit between the EFI and EFD
processing. Hence the EFI can be freed even before the EFD is
created using such a method.
Further, log recovery uses the AIL for tracking EFI/EFDs that need
to be recovered, but it uses the AIL *differently* to the EFI
transaction commit. Hence log recovery never pins or unpins EFIs, so
we can't drop the EFI reference count indirectly to free the EFI.
However, this doesn't prevent us from using a reference count here.
There is a 1:1 relationship between EFIs and EFDs, so when we
initialise the EFI we can take a reference count for the EFD as
well. This solves the xfs_bmap_finish() issue - the EFI will never
be freed until the EFD is processed. In terms of log recovery,
during the committing of the EFD we can look for the
XFS_EFI_RECOVERED bit being set and drop the EFI reference as well,
thereby ensuring everything works correctly there as well.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2013-04-03 11:09:21 +08:00
|
|
|
* the lsn at which it's been logged.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
STATIC xfs_lsn_t
|
2010-06-23 16:11:15 +08:00
|
|
|
xfs_efi_item_committed(
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
xfs_lsn_t lsn)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
return lsn;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The EFI dependency tracking op doesn't do squat. It can't because
|
|
|
|
* it doesn't know where the free extent is coming from. The dependency
|
|
|
|
* tracking has to be handled by the "enclosing" metadata object. For
|
|
|
|
* example, for inodes, the inode is locked throughout the extent freeing
|
|
|
|
* so the dependency should be recorded there.
|
|
|
|
*/
|
|
|
|
STATIC void
|
2010-06-23 16:11:15 +08:00
|
|
|
xfs_efi_item_committing(
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
xfs_lsn_t lsn)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is the ops vector shared by all efi log items.
|
|
|
|
*/
|
2011-10-28 17:54:24 +08:00
|
|
|
static const struct xfs_item_ops xfs_efi_item_ops = {
|
2010-06-23 16:11:15 +08:00
|
|
|
.iop_size = xfs_efi_item_size,
|
|
|
|
.iop_format = xfs_efi_item_format,
|
|
|
|
.iop_pin = xfs_efi_item_pin,
|
|
|
|
.iop_unpin = xfs_efi_item_unpin,
|
|
|
|
.iop_unlock = xfs_efi_item_unlock,
|
|
|
|
.iop_committed = xfs_efi_item_committed,
|
|
|
|
.iop_push = xfs_efi_item_push,
|
|
|
|
.iop_committing = xfs_efi_item_committing
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Allocate and initialize an efi item with the given number of extents.
|
|
|
|
*/
|
2010-06-23 16:11:15 +08:00
|
|
|
struct xfs_efi_log_item *
|
|
|
|
xfs_efi_init(
|
|
|
|
struct xfs_mount *mp,
|
|
|
|
uint nextents)
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
{
|
2010-06-23 16:11:15 +08:00
|
|
|
struct xfs_efi_log_item *efip;
|
2005-04-17 06:20:36 +08:00
|
|
|
uint size;
|
|
|
|
|
|
|
|
ASSERT(nextents > 0);
|
|
|
|
if (nextents > XFS_EFI_MAX_FAST_EXTENTS) {
|
|
|
|
size = (uint)(sizeof(xfs_efi_log_item_t) +
|
|
|
|
((nextents - 1) * sizeof(xfs_extent_t)));
|
2010-06-23 16:11:15 +08:00
|
|
|
efip = kmem_zalloc(size, KM_SLEEP);
|
2005-04-17 06:20:36 +08:00
|
|
|
} else {
|
2010-06-23 16:11:15 +08:00
|
|
|
efip = kmem_zone_zalloc(xfs_efi_zone, KM_SLEEP);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2010-03-23 07:10:00 +08:00
|
|
|
xfs_log_item_init(mp, &efip->efi_item, XFS_LI_EFI, &xfs_efi_item_ops);
|
2005-04-17 06:20:36 +08:00
|
|
|
efip->efi_format.efi_nextents = nextents;
|
|
|
|
efip->efi_format.efi_id = (__psint_t)(void*)efip;
|
2010-12-20 08:59:49 +08:00
|
|
|
atomic_set(&efip->efi_next_extent, 0);
|
xfs: don't free EFIs before the EFDs are committed
Filesystems are occasionally being shut down with this error:
xfs_trans_ail_delete_bulk: attempting to delete a log item that is
not in the AIL.
It was diagnosed to be related to the EFI/EFD commit order when the
EFI and EFD are in different checkpoints and the EFD is committed
before the EFI here:
http://oss.sgi.com/archives/xfs/2013-01/msg00082.html
The real problem is that a single bit cannot fully describe the
states that the EFI/EFD processing can be in. These completion
states are:
EFI EFI in AIL EFD Result
committed/unpinned Yes committed OK
committed/pinned No committed Shutdown
uncommitted No committed Shutdown
Note that the "result" field is what should happen, not what does
happen. The current logic is broken and handles the first two cases
correctly by luck. That is, the code will free the EFI if the
XFS_EFI_COMMITTED bit is *not* set, rather than if it is set. The
inverted logic "works" because if both EFI and EFD are committed,
then the first __xfs_efi_release() call clears the XFS_EFI_COMMITTED
bit, and the second frees the EFI item. Hence as long as
xfs_efi_item_committed() has been called, everything appears to be
fine.
It is the third case where the logic fails - where
xfs_efd_item_committed() is called before xfs_efi_item_committed(),
and that results in the EFI being freed before it has been
committed. That is the bug that triggered the shutdown, and hence
keeping track of whether the EFI has been committed or not is
insufficient to correctly order the EFI/EFD operations w.r.t. the
AIL.
What we really want is this: the EFI is always placed into the
AIL before the last reference goes away. The only way to guarantee
that is that the EFI is not freed until after it has been unpinned
*and* the EFD has been committed. That is, restructure the logic so
that the only case that can occur is the first case.
This can be done easily by replacing the XFS_EFI_COMMITTED with an
EFI reference count. The EFI is initialised with it's own count, and
that is not released until it is unpinned. However, there is a
complication to this method - the high level EFI/EFD code in
xfs_bmap_finish() does not hold direct references to the EFI
structure, and runs a transaction commit between the EFI and EFD
processing. Hence the EFI can be freed even before the EFD is
created using such a method.
Further, log recovery uses the AIL for tracking EFI/EFDs that need
to be recovered, but it uses the AIL *differently* to the EFI
transaction commit. Hence log recovery never pins or unpins EFIs, so
we can't drop the EFI reference count indirectly to free the EFI.
However, this doesn't prevent us from using a reference count here.
There is a 1:1 relationship between EFIs and EFDs, so when we
initialise the EFI we can take a reference count for the EFD as
well. This solves the xfs_bmap_finish() issue - the EFI will never
be freed until the EFD is processed. In terms of log recovery,
during the committing of the EFD we can look for the
XFS_EFI_RECOVERED bit being set and drop the EFI reference as well,
thereby ensuring everything works correctly there as well.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2013-04-03 11:09:21 +08:00
|
|
|
atomic_set(&efip->efi_refcount, 2);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-06-23 16:11:15 +08:00
|
|
|
return efip;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2006-06-09 12:55:38 +08:00
|
|
|
/*
|
|
|
|
* Copy an EFI format buffer from the given buf, and into the destination
|
|
|
|
* EFI format structure.
|
|
|
|
* The given buffer can be in 32 bit or 64 bit form (which has different padding),
|
|
|
|
* one of which will be the native format for this kernel.
|
|
|
|
* It will handle the conversion of formats if necessary.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
xfs_efi_copy_format(xfs_log_iovec_t *buf, xfs_efi_log_format_t *dst_efi_fmt)
|
|
|
|
{
|
2010-06-23 16:11:15 +08:00
|
|
|
xfs_efi_log_format_t *src_efi_fmt = buf->i_addr;
|
2006-06-09 12:55:38 +08:00
|
|
|
uint i;
|
|
|
|
uint len = sizeof(xfs_efi_log_format_t) +
|
|
|
|
(src_efi_fmt->efi_nextents - 1) * sizeof(xfs_extent_t);
|
|
|
|
uint len32 = sizeof(xfs_efi_log_format_32_t) +
|
|
|
|
(src_efi_fmt->efi_nextents - 1) * sizeof(xfs_extent_32_t);
|
|
|
|
uint len64 = sizeof(xfs_efi_log_format_64_t) +
|
|
|
|
(src_efi_fmt->efi_nextents - 1) * sizeof(xfs_extent_64_t);
|
|
|
|
|
|
|
|
if (buf->i_len == len) {
|
|
|
|
memcpy((char *)dst_efi_fmt, (char*)src_efi_fmt, len);
|
|
|
|
return 0;
|
|
|
|
} else if (buf->i_len == len32) {
|
2010-06-23 16:11:15 +08:00
|
|
|
xfs_efi_log_format_32_t *src_efi_fmt_32 = buf->i_addr;
|
2006-06-09 12:55:38 +08:00
|
|
|
|
|
|
|
dst_efi_fmt->efi_type = src_efi_fmt_32->efi_type;
|
|
|
|
dst_efi_fmt->efi_size = src_efi_fmt_32->efi_size;
|
|
|
|
dst_efi_fmt->efi_nextents = src_efi_fmt_32->efi_nextents;
|
|
|
|
dst_efi_fmt->efi_id = src_efi_fmt_32->efi_id;
|
|
|
|
for (i = 0; i < dst_efi_fmt->efi_nextents; i++) {
|
|
|
|
dst_efi_fmt->efi_extents[i].ext_start =
|
|
|
|
src_efi_fmt_32->efi_extents[i].ext_start;
|
|
|
|
dst_efi_fmt->efi_extents[i].ext_len =
|
|
|
|
src_efi_fmt_32->efi_extents[i].ext_len;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
} else if (buf->i_len == len64) {
|
2010-06-23 16:11:15 +08:00
|
|
|
xfs_efi_log_format_64_t *src_efi_fmt_64 = buf->i_addr;
|
2006-06-09 12:55:38 +08:00
|
|
|
|
|
|
|
dst_efi_fmt->efi_type = src_efi_fmt_64->efi_type;
|
|
|
|
dst_efi_fmt->efi_size = src_efi_fmt_64->efi_size;
|
|
|
|
dst_efi_fmt->efi_nextents = src_efi_fmt_64->efi_nextents;
|
|
|
|
dst_efi_fmt->efi_id = src_efi_fmt_64->efi_id;
|
|
|
|
for (i = 0; i < dst_efi_fmt->efi_nextents; i++) {
|
|
|
|
dst_efi_fmt->efi_extents[i].ext_start =
|
|
|
|
src_efi_fmt_64->efi_extents[i].ext_start;
|
|
|
|
dst_efi_fmt->efi_extents[i].ext_len =
|
|
|
|
src_efi_fmt_64->efi_extents[i].ext_len;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
2014-06-25 12:58:08 +08:00
|
|
|
return -EFSCORRUPTED;
|
2006-06-09 12:55:38 +08:00
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
2010-12-20 08:59:49 +08:00
|
|
|
* This is called by the efd item code below to release references to the given
|
|
|
|
* efi item. Each efd calls this with the number of extents that it has
|
|
|
|
* logged, and when the sum of these reaches the total number of extents logged
|
|
|
|
* by this efi item we can free the efi item.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
xfs_efi_release(xfs_efi_log_item_t *efip,
|
|
|
|
uint nextents)
|
|
|
|
{
|
2010-12-20 08:59:49 +08:00
|
|
|
ASSERT(atomic_read(&efip->efi_next_extent) >= nextents);
|
xfs: don't free EFIs before the EFDs are committed
Filesystems are occasionally being shut down with this error:
xfs_trans_ail_delete_bulk: attempting to delete a log item that is
not in the AIL.
It was diagnosed to be related to the EFI/EFD commit order when the
EFI and EFD are in different checkpoints and the EFD is committed
before the EFI here:
http://oss.sgi.com/archives/xfs/2013-01/msg00082.html
The real problem is that a single bit cannot fully describe the
states that the EFI/EFD processing can be in. These completion
states are:
EFI EFI in AIL EFD Result
committed/unpinned Yes committed OK
committed/pinned No committed Shutdown
uncommitted No committed Shutdown
Note that the "result" field is what should happen, not what does
happen. The current logic is broken and handles the first two cases
correctly by luck. That is, the code will free the EFI if the
XFS_EFI_COMMITTED bit is *not* set, rather than if it is set. The
inverted logic "works" because if both EFI and EFD are committed,
then the first __xfs_efi_release() call clears the XFS_EFI_COMMITTED
bit, and the second frees the EFI item. Hence as long as
xfs_efi_item_committed() has been called, everything appears to be
fine.
It is the third case where the logic fails - where
xfs_efd_item_committed() is called before xfs_efi_item_committed(),
and that results in the EFI being freed before it has been
committed. That is the bug that triggered the shutdown, and hence
keeping track of whether the EFI has been committed or not is
insufficient to correctly order the EFI/EFD operations w.r.t. the
AIL.
What we really want is this: the EFI is always placed into the
AIL before the last reference goes away. The only way to guarantee
that is that the EFI is not freed until after it has been unpinned
*and* the EFD has been committed. That is, restructure the logic so
that the only case that can occur is the first case.
This can be done easily by replacing the XFS_EFI_COMMITTED with an
EFI reference count. The EFI is initialised with it's own count, and
that is not released until it is unpinned. However, there is a
complication to this method - the high level EFI/EFD code in
xfs_bmap_finish() does not hold direct references to the EFI
structure, and runs a transaction commit between the EFI and EFD
processing. Hence the EFI can be freed even before the EFD is
created using such a method.
Further, log recovery uses the AIL for tracking EFI/EFDs that need
to be recovered, but it uses the AIL *differently* to the EFI
transaction commit. Hence log recovery never pins or unpins EFIs, so
we can't drop the EFI reference count indirectly to free the EFI.
However, this doesn't prevent us from using a reference count here.
There is a 1:1 relationship between EFIs and EFDs, so when we
initialise the EFI we can take a reference count for the EFD as
well. This solves the xfs_bmap_finish() issue - the EFI will never
be freed until the EFD is processed. In terms of log recovery,
during the committing of the EFD we can look for the
XFS_EFI_RECOVERED bit being set and drop the EFI reference as well,
thereby ensuring everything works correctly there as well.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2013-04-03 11:09:21 +08:00
|
|
|
if (atomic_sub_and_test(nextents, &efip->efi_next_extent)) {
|
|
|
|
/* recovery needs us to drop the EFI reference, too */
|
|
|
|
if (test_bit(XFS_EFI_RECOVERED, &efip->efi_flags))
|
|
|
|
__xfs_efi_release(efip);
|
2013-05-20 07:51:10 +08:00
|
|
|
|
|
|
|
__xfs_efi_release(efip);
|
|
|
|
/* efip may now have been freed, do not reference it again. */
|
xfs: don't free EFIs before the EFDs are committed
Filesystems are occasionally being shut down with this error:
xfs_trans_ail_delete_bulk: attempting to delete a log item that is
not in the AIL.
It was diagnosed to be related to the EFI/EFD commit order when the
EFI and EFD are in different checkpoints and the EFD is committed
before the EFI here:
http://oss.sgi.com/archives/xfs/2013-01/msg00082.html
The real problem is that a single bit cannot fully describe the
states that the EFI/EFD processing can be in. These completion
states are:
EFI EFI in AIL EFD Result
committed/unpinned Yes committed OK
committed/pinned No committed Shutdown
uncommitted No committed Shutdown
Note that the "result" field is what should happen, not what does
happen. The current logic is broken and handles the first two cases
correctly by luck. That is, the code will free the EFI if the
XFS_EFI_COMMITTED bit is *not* set, rather than if it is set. The
inverted logic "works" because if both EFI and EFD are committed,
then the first __xfs_efi_release() call clears the XFS_EFI_COMMITTED
bit, and the second frees the EFI item. Hence as long as
xfs_efi_item_committed() has been called, everything appears to be
fine.
It is the third case where the logic fails - where
xfs_efd_item_committed() is called before xfs_efi_item_committed(),
and that results in the EFI being freed before it has been
committed. That is the bug that triggered the shutdown, and hence
keeping track of whether the EFI has been committed or not is
insufficient to correctly order the EFI/EFD operations w.r.t. the
AIL.
What we really want is this: the EFI is always placed into the
AIL before the last reference goes away. The only way to guarantee
that is that the EFI is not freed until after it has been unpinned
*and* the EFD has been committed. That is, restructure the logic so
that the only case that can occur is the first case.
This can be done easily by replacing the XFS_EFI_COMMITTED with an
EFI reference count. The EFI is initialised with it's own count, and
that is not released until it is unpinned. However, there is a
complication to this method - the high level EFI/EFD code in
xfs_bmap_finish() does not hold direct references to the EFI
structure, and runs a transaction commit between the EFI and EFD
processing. Hence the EFI can be freed even before the EFD is
created using such a method.
Further, log recovery uses the AIL for tracking EFI/EFDs that need
to be recovered, but it uses the AIL *differently* to the EFI
transaction commit. Hence log recovery never pins or unpins EFIs, so
we can't drop the EFI reference count indirectly to free the EFI.
However, this doesn't prevent us from using a reference count here.
There is a 1:1 relationship between EFIs and EFDs, so when we
initialise the EFI we can take a reference count for the EFD as
well. This solves the xfs_bmap_finish() issue - the EFI will never
be freed until the EFD is processed. In terms of log recovery,
during the committing of the EFD we can look for the
XFS_EFI_RECOVERED bit being set and drop the EFI reference as well,
thereby ensuring everything works correctly there as well.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2013-04-03 11:09:21 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2010-06-23 16:11:15 +08:00
|
|
|
static inline struct xfs_efd_log_item *EFD_ITEM(struct xfs_log_item *lip)
|
2005-06-21 13:41:19 +08:00
|
|
|
{
|
2010-06-23 16:11:15 +08:00
|
|
|
return container_of(lip, struct xfs_efd_log_item, efd_item);
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-06-23 16:11:15 +08:00
|
|
|
STATIC void
|
|
|
|
xfs_efd_item_free(struct xfs_efd_log_item *efdp)
|
|
|
|
{
|
|
|
|
if (efdp->efd_format.efd_nextents > XFS_EFD_MAX_FAST_EXTENTS)
|
2008-05-19 14:31:57 +08:00
|
|
|
kmem_free(efdp);
|
2010-06-23 16:11:15 +08:00
|
|
|
else
|
2005-06-21 13:41:19 +08:00
|
|
|
kmem_zone_free(xfs_efd_zone, efdp);
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* This returns the number of iovecs needed to log the given efd item.
|
|
|
|
* We only need 1 iovec for an efd item. It just logs the efd_log_format
|
|
|
|
* structure.
|
|
|
|
*/
|
2013-08-12 18:50:04 +08:00
|
|
|
static inline int
|
|
|
|
xfs_efd_item_sizeof(
|
|
|
|
struct xfs_efd_log_item *efdp)
|
|
|
|
{
|
|
|
|
return sizeof(xfs_efd_log_format_t) +
|
|
|
|
(efdp->efd_format.efd_nextents - 1) * sizeof(xfs_extent_t);
|
|
|
|
}
|
|
|
|
|
|
|
|
STATIC void
|
2010-06-23 16:11:15 +08:00
|
|
|
xfs_efd_item_size(
|
2013-08-12 18:50:04 +08:00
|
|
|
struct xfs_log_item *lip,
|
|
|
|
int *nvecs,
|
|
|
|
int *nbytes)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2013-08-12 18:50:04 +08:00
|
|
|
*nvecs += 1;
|
|
|
|
*nbytes += xfs_efd_item_sizeof(EFD_ITEM(lip));
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is called to fill in the vector of log iovecs for the
|
|
|
|
* given efd log item. We use only 1 iovec, and we point that
|
|
|
|
* at the efd_log_format structure embedded in the efd item.
|
|
|
|
* It is at this point that we assert that all of the extent
|
|
|
|
* slots in the efd item have been filled.
|
|
|
|
*/
|
|
|
|
STATIC void
|
2010-06-23 16:11:15 +08:00
|
|
|
xfs_efd_item_format(
|
|
|
|
struct xfs_log_item *lip,
|
2013-12-13 08:34:02 +08:00
|
|
|
struct xfs_log_vec *lv)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2010-06-23 16:11:15 +08:00
|
|
|
struct xfs_efd_log_item *efdp = EFD_ITEM(lip);
|
2013-12-13 08:34:02 +08:00
|
|
|
struct xfs_log_iovec *vecp = NULL;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
ASSERT(efdp->efd_next_extent == efdp->efd_format.efd_nextents);
|
|
|
|
|
|
|
|
efdp->efd_format.efd_type = XFS_LI_EFD;
|
|
|
|
efdp->efd_format.efd_size = 1;
|
|
|
|
|
2013-12-13 08:34:02 +08:00
|
|
|
xlog_copy_iovec(lv, &vecp, XLOG_REG_TYPE_EFD_FORMAT,
|
2013-12-13 08:00:43 +08:00
|
|
|
&efdp->efd_format,
|
|
|
|
xfs_efd_item_sizeof(efdp));
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Pinning has no meaning for an efd item, so just return.
|
|
|
|
*/
|
|
|
|
STATIC void
|
2010-06-23 16:11:15 +08:00
|
|
|
xfs_efd_item_pin(
|
|
|
|
struct xfs_log_item *lip)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Since pinning has no meaning for an efd item, unpinning does
|
|
|
|
* not either.
|
|
|
|
*/
|
|
|
|
STATIC void
|
2010-06-23 16:11:15 +08:00
|
|
|
xfs_efd_item_unpin(
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
int remove)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 13:58:39 +08:00
|
|
|
* There isn't much you can do to push on an efd item. It is simply stuck
|
|
|
|
* waiting for the log to be flushed to disk.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
STATIC uint
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 13:58:39 +08:00
|
|
|
xfs_efd_item_push(
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
struct list_head *buffer_list)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 13:58:39 +08:00
|
|
|
return XFS_ITEM_PINNED;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
STATIC void
|
2010-06-23 16:11:15 +08:00
|
|
|
xfs_efd_item_unlock(
|
|
|
|
struct xfs_log_item *lip)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2010-06-23 16:11:15 +08:00
|
|
|
if (lip->li_flags & XFS_LI_ABORTED)
|
|
|
|
xfs_efd_item_free(EFD_ITEM(lip));
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When the efd item is committed to disk, all we need to do
|
|
|
|
* is delete our reference to our partner efi item and then
|
|
|
|
* free ourselves. Since we're freeing ourselves we must
|
|
|
|
* return -1 to keep the transaction code from further referencing
|
|
|
|
* this item.
|
|
|
|
*/
|
|
|
|
STATIC xfs_lsn_t
|
2010-06-23 16:11:15 +08:00
|
|
|
xfs_efd_item_committed(
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
xfs_lsn_t lsn)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2010-06-23 16:11:15 +08:00
|
|
|
struct xfs_efd_log_item *efdp = EFD_ITEM(lip);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* If we got a log I/O error, it's always the case that the LR with the
|
|
|
|
* EFI got unpinned and freed before the EFD got aborted.
|
|
|
|
*/
|
2010-06-23 16:11:15 +08:00
|
|
|
if (!(lip->li_flags & XFS_LI_ABORTED))
|
2005-04-17 06:20:36 +08:00
|
|
|
xfs_efi_release(efdp->efd_efip, efdp->efd_format.efd_nextents);
|
|
|
|
|
2005-06-21 13:41:19 +08:00
|
|
|
xfs_efd_item_free(efdp);
|
2005-04-17 06:20:36 +08:00
|
|
|
return (xfs_lsn_t)-1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The EFD dependency tracking op doesn't do squat. It can't because
|
|
|
|
* it doesn't know where the free extent is coming from. The dependency
|
|
|
|
* tracking has to be handled by the "enclosing" metadata object. For
|
|
|
|
* example, for inodes, the inode is locked throughout the extent freeing
|
|
|
|
* so the dependency should be recorded there.
|
|
|
|
*/
|
|
|
|
STATIC void
|
2010-06-23 16:11:15 +08:00
|
|
|
xfs_efd_item_committing(
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
xfs_lsn_t lsn)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is the ops vector shared by all efd log items.
|
|
|
|
*/
|
2011-10-28 17:54:24 +08:00
|
|
|
static const struct xfs_item_ops xfs_efd_item_ops = {
|
2010-06-23 16:11:15 +08:00
|
|
|
.iop_size = xfs_efd_item_size,
|
|
|
|
.iop_format = xfs_efd_item_format,
|
|
|
|
.iop_pin = xfs_efd_item_pin,
|
|
|
|
.iop_unpin = xfs_efd_item_unpin,
|
|
|
|
.iop_unlock = xfs_efd_item_unlock,
|
|
|
|
.iop_committed = xfs_efd_item_committed,
|
|
|
|
.iop_push = xfs_efd_item_push,
|
|
|
|
.iop_committing = xfs_efd_item_committing
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Allocate and initialize an efd item with the given number of extents.
|
|
|
|
*/
|
2010-06-23 16:11:15 +08:00
|
|
|
struct xfs_efd_log_item *
|
|
|
|
xfs_efd_init(
|
|
|
|
struct xfs_mount *mp,
|
|
|
|
struct xfs_efi_log_item *efip,
|
|
|
|
uint nextents)
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
{
|
2010-06-23 16:11:15 +08:00
|
|
|
struct xfs_efd_log_item *efdp;
|
2005-04-17 06:20:36 +08:00
|
|
|
uint size;
|
|
|
|
|
|
|
|
ASSERT(nextents > 0);
|
|
|
|
if (nextents > XFS_EFD_MAX_FAST_EXTENTS) {
|
|
|
|
size = (uint)(sizeof(xfs_efd_log_item_t) +
|
|
|
|
((nextents - 1) * sizeof(xfs_extent_t)));
|
2010-06-23 16:11:15 +08:00
|
|
|
efdp = kmem_zalloc(size, KM_SLEEP);
|
2005-04-17 06:20:36 +08:00
|
|
|
} else {
|
2010-06-23 16:11:15 +08:00
|
|
|
efdp = kmem_zone_zalloc(xfs_efd_zone, KM_SLEEP);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2010-03-23 07:10:00 +08:00
|
|
|
xfs_log_item_init(mp, &efdp->efd_item, XFS_LI_EFD, &xfs_efd_item_ops);
|
2005-04-17 06:20:36 +08:00
|
|
|
efdp->efd_efip = efip;
|
|
|
|
efdp->efd_format.efd_nextents = nextents;
|
|
|
|
efdp->efd_format.efd_efi_id = efip->efi_format.efi_id;
|
|
|
|
|
2010-06-23 16:11:15 +08:00
|
|
|
return efdp;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|