2018-06-06 02:42:14 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0+
|
2016-10-03 16:11:25 +00:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2016 Oracle. All Rights Reserved.
|
|
|
|
* Author: Darrick J. Wong <darrick.wong@oracle.com>
|
|
|
|
*/
|
|
|
|
#include "xfs.h"
|
|
|
|
#include "xfs_fs.h"
|
|
|
|
#include "xfs_format.h"
|
|
|
|
#include "xfs_log_format.h"
|
|
|
|
#include "xfs_trans_resv.h"
|
2016-10-03 16:11:26 +00:00
|
|
|
#include "xfs_bit.h"
|
2019-06-29 02:25:35 +00:00
|
|
|
#include "xfs_shared.h"
|
2016-10-03 16:11:25 +00:00
|
|
|
#include "xfs_mount.h"
|
2016-10-03 16:11:26 +00:00
|
|
|
#include "xfs_defer.h"
|
|
|
|
#include "xfs_inode.h"
|
2016-10-03 16:11:25 +00:00
|
|
|
#include "xfs_trans.h"
|
|
|
|
#include "xfs_trans_priv.h"
|
|
|
|
#include "xfs_bmap_item.h"
|
|
|
|
#include "xfs_log.h"
|
2016-10-03 16:11:26 +00:00
|
|
|
#include "xfs_bmap.h"
|
|
|
|
#include "xfs_icache.h"
|
2017-04-12 19:26:07 +00:00
|
|
|
#include "xfs_bmap_btree.h"
|
|
|
|
#include "xfs_trans_space.h"
|
2019-11-02 16:40:53 +00:00
|
|
|
#include "xfs_error.h"
|
2020-05-01 23:00:50 +00:00
|
|
|
#include "xfs_log_priv.h"
|
2020-05-01 23:00:45 +00:00
|
|
|
#include "xfs_log_recover.h"
|
2023-04-12 01:59:53 +00:00
|
|
|
#include "xfs_ag.h"
|
2016-10-03 16:11:25 +00:00
|
|
|
|
2021-10-12 18:09:23 +00:00
|
|
|
struct kmem_cache *xfs_bui_cache;
|
|
|
|
struct kmem_cache *xfs_bud_cache;
|
2016-10-03 16:11:25 +00:00
|
|
|
|
2020-05-01 23:00:52 +00:00
|
|
|
static const struct xfs_item_ops xfs_bui_item_ops;
|
|
|
|
|
2016-10-03 16:11:25 +00:00
|
|
|
static inline struct xfs_bui_log_item *BUI_ITEM(struct xfs_log_item *lip)
|
|
|
|
{
|
|
|
|
return container_of(lip, struct xfs_bui_log_item, bui_item);
|
|
|
|
}
|
|
|
|
|
2020-05-01 23:00:50 +00:00
|
|
|
STATIC void
|
2016-10-03 16:11:25 +00:00
|
|
|
xfs_bui_item_free(
|
|
|
|
struct xfs_bui_log_item *buip)
|
|
|
|
{
|
2022-05-04 01:45:11 +00:00
|
|
|
kmem_free(buip->bui_item.li_lv_shadow);
|
2021-10-12 18:09:23 +00:00
|
|
|
kmem_cache_free(xfs_bui_cache, buip);
|
2016-10-03 16:11:25 +00:00
|
|
|
}
|
|
|
|
|
2018-04-03 03:08:27 +00:00
|
|
|
/*
|
|
|
|
* Freeing the BUI requires that we remove it from the AIL if it has already
|
|
|
|
* been placed there. However, the BUI may not yet have been placed in the AIL
|
|
|
|
* when called by xfs_bui_release() from BUD processing due to the ordering of
|
|
|
|
* committed vs unpin operations in bulk insert operations. Hence the reference
|
|
|
|
* count to ensure only the last caller frees the BUI.
|
|
|
|
*/
|
2020-05-01 23:00:52 +00:00
|
|
|
STATIC void
|
2018-04-03 03:08:27 +00:00
|
|
|
xfs_bui_release(
|
|
|
|
struct xfs_bui_log_item *buip)
|
|
|
|
{
|
|
|
|
ASSERT(atomic_read(&buip->bui_refcount) > 0);
|
2022-05-04 01:46:47 +00:00
|
|
|
if (!atomic_dec_and_test(&buip->bui_refcount))
|
|
|
|
return;
|
|
|
|
|
|
|
|
xfs_trans_ail_delete(&buip->bui_item, 0);
|
|
|
|
xfs_bui_item_free(buip);
|
2018-04-03 03:08:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2016-10-03 16:11:25 +00:00
|
|
|
STATIC void
|
|
|
|
xfs_bui_item_size(
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
int *nvecs,
|
|
|
|
int *nbytes)
|
|
|
|
{
|
|
|
|
struct xfs_bui_log_item *buip = BUI_ITEM(lip);
|
|
|
|
|
|
|
|
*nvecs += 1;
|
|
|
|
*nbytes += xfs_bui_log_format_sizeof(buip->bui_format.bui_nextents);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is called to fill in the vector of log iovecs for the
|
|
|
|
* given bui log item. We use only 1 iovec, and we point that
|
|
|
|
* at the bui_log_format structure embedded in the bui item.
|
|
|
|
* It is at this point that we assert that all of the extent
|
|
|
|
* slots in the bui item have been filled.
|
|
|
|
*/
|
|
|
|
STATIC void
|
|
|
|
xfs_bui_item_format(
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
struct xfs_log_vec *lv)
|
|
|
|
{
|
|
|
|
struct xfs_bui_log_item *buip = BUI_ITEM(lip);
|
|
|
|
struct xfs_log_iovec *vecp = NULL;
|
|
|
|
|
|
|
|
ASSERT(atomic_read(&buip->bui_next_extent) ==
|
|
|
|
buip->bui_format.bui_nextents);
|
|
|
|
|
|
|
|
buip->bui_format.bui_type = XFS_LI_BUI;
|
|
|
|
buip->bui_format.bui_size = 1;
|
|
|
|
|
|
|
|
xlog_copy_iovec(lv, &vecp, XLOG_REG_TYPE_BUI_FORMAT, &buip->bui_format,
|
|
|
|
xfs_bui_log_format_sizeof(buip->bui_format.bui_nextents));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The unpin operation is the last place an BUI is manipulated in the log. It is
|
|
|
|
* either inserted in the AIL or aborted in the event of a log I/O error. In
|
|
|
|
* either case, the BUI transaction has been successfully committed to make it
|
|
|
|
* this far. Therefore, we expect whoever committed the BUI to either construct
|
|
|
|
* and commit the BUD or drop the BUD's reference in the event of error. Simply
|
|
|
|
* drop the log's BUI reference now that the log is done with it.
|
|
|
|
*/
|
|
|
|
STATIC void
|
|
|
|
xfs_bui_item_unpin(
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
int remove)
|
|
|
|
{
|
|
|
|
struct xfs_bui_log_item *buip = BUI_ITEM(lip);
|
|
|
|
|
|
|
|
xfs_bui_release(buip);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The BUI has been either committed or aborted if the transaction has been
|
|
|
|
* cancelled. If the transaction was cancelled, an BUD isn't going to be
|
|
|
|
* constructed and thus we free the BUI here directly.
|
|
|
|
*/
|
|
|
|
STATIC void
|
2019-06-29 02:27:32 +00:00
|
|
|
xfs_bui_item_release(
|
2016-10-03 16:11:25 +00:00
|
|
|
struct xfs_log_item *lip)
|
|
|
|
{
|
2019-06-29 02:27:32 +00:00
|
|
|
xfs_bui_release(BUI_ITEM(lip));
|
2016-10-03 16:11:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Allocate and initialize an bui item with the given number of extents.
|
|
|
|
*/
|
2020-05-01 23:00:50 +00:00
|
|
|
STATIC struct xfs_bui_log_item *
|
2016-10-03 16:11:25 +00:00
|
|
|
xfs_bui_init(
|
|
|
|
struct xfs_mount *mp)
|
|
|
|
|
|
|
|
{
|
|
|
|
struct xfs_bui_log_item *buip;
|
|
|
|
|
2021-10-12 18:09:23 +00:00
|
|
|
buip = kmem_cache_zalloc(xfs_bui_cache, GFP_KERNEL | __GFP_NOFAIL);
|
2016-10-03 16:11:25 +00:00
|
|
|
|
|
|
|
xfs_log_item_init(mp, &buip->bui_item, XFS_LI_BUI, &xfs_bui_item_ops);
|
|
|
|
buip->bui_format.bui_nextents = XFS_BUI_MAX_FAST_EXTENTS;
|
|
|
|
buip->bui_format.bui_id = (uintptr_t)(void *)buip;
|
|
|
|
atomic_set(&buip->bui_next_extent, 0);
|
|
|
|
atomic_set(&buip->bui_refcount, 2);
|
|
|
|
|
|
|
|
return buip;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct xfs_bud_log_item *BUD_ITEM(struct xfs_log_item *lip)
|
|
|
|
{
|
|
|
|
return container_of(lip, struct xfs_bud_log_item, bud_item);
|
|
|
|
}
|
|
|
|
|
|
|
|
STATIC void
|
|
|
|
xfs_bud_item_size(
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
int *nvecs,
|
|
|
|
int *nbytes)
|
|
|
|
{
|
|
|
|
*nvecs += 1;
|
|
|
|
*nbytes += sizeof(struct xfs_bud_log_format);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is called to fill in the vector of log iovecs for the
|
|
|
|
* given bud log item. We use only 1 iovec, and we point that
|
|
|
|
* at the bud_log_format structure embedded in the bud item.
|
|
|
|
* It is at this point that we assert that all of the extent
|
|
|
|
* slots in the bud item have been filled.
|
|
|
|
*/
|
|
|
|
STATIC void
|
|
|
|
xfs_bud_item_format(
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
struct xfs_log_vec *lv)
|
|
|
|
{
|
|
|
|
struct xfs_bud_log_item *budp = BUD_ITEM(lip);
|
|
|
|
struct xfs_log_iovec *vecp = NULL;
|
|
|
|
|
|
|
|
budp->bud_format.bud_type = XFS_LI_BUD;
|
|
|
|
budp->bud_format.bud_size = 1;
|
|
|
|
|
|
|
|
xlog_copy_iovec(lv, &vecp, XLOG_REG_TYPE_BUD_FORMAT, &budp->bud_format,
|
|
|
|
sizeof(struct xfs_bud_log_format));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The BUD is either committed or aborted if the transaction is cancelled. If
|
|
|
|
* the transaction is cancelled, drop our reference to the BUI and free the
|
|
|
|
* BUD.
|
|
|
|
*/
|
|
|
|
STATIC void
|
2019-06-29 02:27:32 +00:00
|
|
|
xfs_bud_item_release(
|
2016-10-03 16:11:25 +00:00
|
|
|
struct xfs_log_item *lip)
|
|
|
|
{
|
|
|
|
struct xfs_bud_log_item *budp = BUD_ITEM(lip);
|
|
|
|
|
2019-06-29 02:27:32 +00:00
|
|
|
xfs_bui_release(budp->bud_buip);
|
2022-05-04 01:45:11 +00:00
|
|
|
kmem_free(budp->bud_item.li_lv_shadow);
|
2021-10-12 18:09:23 +00:00
|
|
|
kmem_cache_free(xfs_bud_cache, budp);
|
2016-10-03 16:11:25 +00:00
|
|
|
}
|
|
|
|
|
2022-05-04 01:46:39 +00:00
|
|
|
static struct xfs_log_item *
|
|
|
|
xfs_bud_item_intent(
|
|
|
|
struct xfs_log_item *lip)
|
|
|
|
{
|
|
|
|
return &BUD_ITEM(lip)->bud_buip->bui_item;
|
|
|
|
}
|
|
|
|
|
2016-10-03 16:11:25 +00:00
|
|
|
static const struct xfs_item_ops xfs_bud_item_ops = {
|
2022-05-04 01:46:09 +00:00
|
|
|
.flags = XFS_ITEM_RELEASE_WHEN_COMMITTED |
|
|
|
|
XFS_ITEM_INTENT_DONE,
|
2016-10-03 16:11:25 +00:00
|
|
|
.iop_size = xfs_bud_item_size,
|
|
|
|
.iop_format = xfs_bud_item_format,
|
2019-06-29 02:27:32 +00:00
|
|
|
.iop_release = xfs_bud_item_release,
|
2022-05-04 01:46:39 +00:00
|
|
|
.iop_intent = xfs_bud_item_intent,
|
2016-10-03 16:11:25 +00:00
|
|
|
};
|
|
|
|
|
2019-06-29 02:29:42 +00:00
|
|
|
static struct xfs_bud_log_item *
|
2019-06-29 02:27:36 +00:00
|
|
|
xfs_trans_get_bud(
|
|
|
|
struct xfs_trans *tp,
|
2016-10-03 16:11:25 +00:00
|
|
|
struct xfs_bui_log_item *buip)
|
|
|
|
{
|
2019-06-29 02:27:36 +00:00
|
|
|
struct xfs_bud_log_item *budp;
|
2016-10-03 16:11:25 +00:00
|
|
|
|
2021-10-12 18:09:23 +00:00
|
|
|
budp = kmem_cache_zalloc(xfs_bud_cache, GFP_KERNEL | __GFP_NOFAIL);
|
2019-06-29 02:27:36 +00:00
|
|
|
xfs_log_item_init(tp->t_mountp, &budp->bud_item, XFS_LI_BUD,
|
|
|
|
&xfs_bud_item_ops);
|
2016-10-03 16:11:25 +00:00
|
|
|
budp->bud_buip = buip;
|
|
|
|
budp->bud_format.bud_bui_id = buip->bui_format.bui_id;
|
|
|
|
|
2019-06-29 02:27:36 +00:00
|
|
|
xfs_trans_add_item(tp, &budp->bud_item);
|
2016-10-03 16:11:25 +00:00
|
|
|
return budp;
|
|
|
|
}
|
2016-10-03 16:11:26 +00:00
|
|
|
|
2019-06-29 02:29:42 +00:00
|
|
|
/*
|
|
|
|
* Finish an bmap update and log it to the BUD. Note that the
|
|
|
|
* transaction is marked dirty regardless of whether the bmap update
|
|
|
|
* succeeds or fails to support the BUI/BUD lifecycle rules.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
xfs_trans_log_finish_bmap_update(
|
|
|
|
struct xfs_trans *tp,
|
|
|
|
struct xfs_bud_log_item *budp,
|
2023-02-01 17:50:53 +00:00
|
|
|
struct xfs_bmap_intent *bi)
|
2019-06-29 02:29:42 +00:00
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
2023-02-01 17:50:53 +00:00
|
|
|
error = xfs_bmap_finish_one(tp, bi);
|
2019-06-29 02:29:42 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Mark the transaction dirty, even on error. This ensures the
|
|
|
|
* transaction is aborted, which:
|
|
|
|
*
|
|
|
|
* 1.) releases the BUI and frees the BUD
|
|
|
|
* 2.) shuts down the filesystem
|
|
|
|
*/
|
2022-05-04 01:46:21 +00:00
|
|
|
tp->t_flags |= XFS_TRANS_DIRTY | XFS_TRANS_HAS_INTENT_DONE;
|
2019-06-29 02:29:42 +00:00
|
|
|
set_bit(XFS_LI_DIRTY, &budp->bud_item.li_flags);
|
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Sort bmap intents by inode. */
|
|
|
|
static int
|
|
|
|
xfs_bmap_update_diff_items(
|
|
|
|
void *priv,
|
2021-04-08 18:28:34 +00:00
|
|
|
const struct list_head *a,
|
|
|
|
const struct list_head *b)
|
2019-06-29 02:29:42 +00:00
|
|
|
{
|
|
|
|
struct xfs_bmap_intent *ba;
|
|
|
|
struct xfs_bmap_intent *bb;
|
|
|
|
|
|
|
|
ba = container_of(a, struct xfs_bmap_intent, bi_list);
|
|
|
|
bb = container_of(b, struct xfs_bmap_intent, bi_list);
|
|
|
|
return ba->bi_owner->i_ino - bb->bi_owner->i_ino;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Set the map extent flags for this mapping. */
|
|
|
|
static void
|
|
|
|
xfs_trans_set_bmap_flags(
|
2023-02-01 18:16:01 +00:00
|
|
|
struct xfs_map_extent *map,
|
2019-06-29 02:29:42 +00:00
|
|
|
enum xfs_bmap_intent_type type,
|
|
|
|
int whichfork,
|
|
|
|
xfs_exntst_t state)
|
|
|
|
{
|
2023-02-01 18:16:01 +00:00
|
|
|
map->me_flags = 0;
|
2019-06-29 02:29:42 +00:00
|
|
|
switch (type) {
|
|
|
|
case XFS_BMAP_MAP:
|
|
|
|
case XFS_BMAP_UNMAP:
|
2023-02-01 18:16:01 +00:00
|
|
|
map->me_flags = type;
|
2019-06-29 02:29:42 +00:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
ASSERT(0);
|
|
|
|
}
|
|
|
|
if (state == XFS_EXT_UNWRITTEN)
|
2023-02-01 18:16:01 +00:00
|
|
|
map->me_flags |= XFS_BMAP_EXTENT_UNWRITTEN;
|
2019-06-29 02:29:42 +00:00
|
|
|
if (whichfork == XFS_ATTR_FORK)
|
2023-02-01 18:16:01 +00:00
|
|
|
map->me_flags |= XFS_BMAP_EXTENT_ATTR_FORK;
|
2019-06-29 02:29:42 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Log bmap updates in the intent item. */
|
|
|
|
STATIC void
|
|
|
|
xfs_bmap_update_log_item(
|
|
|
|
struct xfs_trans *tp,
|
2020-04-30 19:52:20 +00:00
|
|
|
struct xfs_bui_log_item *buip,
|
2023-02-01 18:16:01 +00:00
|
|
|
struct xfs_bmap_intent *bi)
|
2019-06-29 02:29:42 +00:00
|
|
|
{
|
|
|
|
uint next_extent;
|
|
|
|
struct xfs_map_extent *map;
|
|
|
|
|
|
|
|
tp->t_flags |= XFS_TRANS_DIRTY;
|
|
|
|
set_bit(XFS_LI_DIRTY, &buip->bui_item.li_flags);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* atomic_inc_return gives us the value after the increment;
|
|
|
|
* we want to use it as an array index so we need to subtract 1 from
|
|
|
|
* it.
|
|
|
|
*/
|
|
|
|
next_extent = atomic_inc_return(&buip->bui_next_extent) - 1;
|
|
|
|
ASSERT(next_extent < buip->bui_format.bui_nextents);
|
|
|
|
map = &buip->bui_format.bui_extents[next_extent];
|
2023-02-01 18:16:01 +00:00
|
|
|
map->me_owner = bi->bi_owner->i_ino;
|
|
|
|
map->me_startblock = bi->bi_bmap.br_startblock;
|
|
|
|
map->me_startoff = bi->bi_bmap.br_startoff;
|
|
|
|
map->me_len = bi->bi_bmap.br_blockcount;
|
|
|
|
xfs_trans_set_bmap_flags(map, bi->bi_type, bi->bi_whichfork,
|
|
|
|
bi->bi_bmap.br_state);
|
2019-06-29 02:29:42 +00:00
|
|
|
}
|
|
|
|
|
2020-04-30 19:52:21 +00:00
|
|
|
static struct xfs_log_item *
|
2020-04-30 19:52:20 +00:00
|
|
|
xfs_bmap_update_create_intent(
|
|
|
|
struct xfs_trans *tp,
|
|
|
|
struct list_head *items,
|
2020-04-30 19:52:20 +00:00
|
|
|
unsigned int count,
|
|
|
|
bool sort)
|
2020-04-30 19:52:20 +00:00
|
|
|
{
|
2020-04-30 19:52:20 +00:00
|
|
|
struct xfs_mount *mp = tp->t_mountp;
|
|
|
|
struct xfs_bui_log_item *buip = xfs_bui_init(mp);
|
2023-02-01 18:16:01 +00:00
|
|
|
struct xfs_bmap_intent *bi;
|
2020-04-30 19:52:20 +00:00
|
|
|
|
|
|
|
ASSERT(count == XFS_BUI_MAX_FAST_EXTENTS);
|
|
|
|
|
|
|
|
xfs_trans_add_item(tp, &buip->bui_item);
|
2020-04-30 19:52:20 +00:00
|
|
|
if (sort)
|
|
|
|
list_sort(mp, items, xfs_bmap_update_diff_items);
|
2023-02-01 18:16:01 +00:00
|
|
|
list_for_each_entry(bi, items, bi_list)
|
|
|
|
xfs_bmap_update_log_item(tp, buip, bi);
|
2020-04-30 19:52:21 +00:00
|
|
|
return &buip->bui_item;
|
2020-04-30 19:52:20 +00:00
|
|
|
}
|
|
|
|
|
2019-06-29 02:29:42 +00:00
|
|
|
/* Get an BUD so we can process all the deferred rmap updates. */
|
2020-04-30 19:52:22 +00:00
|
|
|
static struct xfs_log_item *
|
2019-06-29 02:29:42 +00:00
|
|
|
xfs_bmap_update_create_done(
|
|
|
|
struct xfs_trans *tp,
|
2020-04-30 19:52:21 +00:00
|
|
|
struct xfs_log_item *intent,
|
2019-06-29 02:29:42 +00:00
|
|
|
unsigned int count)
|
|
|
|
{
|
2020-04-30 19:52:22 +00:00
|
|
|
return &xfs_trans_get_bud(tp, BUI_ITEM(intent))->bud_item;
|
2019-06-29 02:29:42 +00:00
|
|
|
}
|
|
|
|
|
2023-04-12 01:59:53 +00:00
|
|
|
/* Take a passive ref to the AG containing the space we're mapping. */
|
|
|
|
void
|
|
|
|
xfs_bmap_update_get_group(
|
|
|
|
struct xfs_mount *mp,
|
|
|
|
struct xfs_bmap_intent *bi)
|
|
|
|
{
|
|
|
|
xfs_agnumber_t agno;
|
|
|
|
|
|
|
|
agno = XFS_FSB_TO_AGNO(mp, bi->bi_bmap.br_startblock);
|
xfs: allow queued AG intents to drain before scrubbing
When a writer thread executes a chain of log intent items, the AG header
buffer locks will cycle during a transaction roll to get from one intent
item to the next in a chain. Although scrub takes all AG header buffer
locks, this isn't sufficient to guard against scrub checking an AG while
that writer thread is in the middle of finishing a chain because there's
no higher level locking primitive guarding allocation groups.
When there's a collision, cross-referencing between data structures
(e.g. rmapbt and refcountbt) yields false corruption events; if repair
is running, this results in incorrect repairs, which is catastrophic.
Fix this by adding to the perag structure the count of active intents
and make scrub wait until it has both AG header buffer locks and the
intent counter reaches zero.
One quirk of the drain code is that deferred bmap updates also bump and
drop the intent counter. A fundamental decision made during the design
phase of the reverse mapping feature is that updates to the rmapbt
records are always made by the same code that updates the primary
metadata. In other words, callers of bmapi functions expect that the
bmapi functions will queue deferred rmap updates.
Some parts of the reflink code queue deferred refcount (CUI) and bmap
(BUI) updates in the same head transaction, but the deferred work
manager completely finishes the CUI before the BUI work is started. As
a result, the CUI drops the intent count long before the deferred rmap
(RUI) update even has a chance to bump the intent count. The only way
to keep the intent count elevated between the CUI and RUI is for the BUI
to bump the counter until the RUI has been created.
A second quirk of the intent drain code is that deferred work items must
increment the intent counter as soon as the work item is added to the
transaction. When a BUI completes and queues an RUI, the RUI must
increment the counter before the BUI decrements it. The only way to
accomplish this is to require that the counter be bumped as soon as the
deferred work item is created in memory.
In the next patches we'll improve on this facility, but this patch
provides the basic functionality.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
2023-04-12 01:59:58 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Bump the intent count on behalf of the deferred rmap and refcount
|
|
|
|
* intent items that that we can queue when we finish this bmap work.
|
|
|
|
* This new intent item will bump the intent count before the bmap
|
|
|
|
* intent drops the intent count, ensuring that the intent count
|
|
|
|
* remains nonzero across the transaction roll.
|
|
|
|
*/
|
|
|
|
bi->bi_pag = xfs_perag_intent_get(mp, agno);
|
2023-04-12 01:59:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Release a passive AG ref after finishing mapping work. */
|
|
|
|
static inline void
|
|
|
|
xfs_bmap_update_put_group(
|
|
|
|
struct xfs_bmap_intent *bi)
|
|
|
|
{
|
xfs: allow queued AG intents to drain before scrubbing
When a writer thread executes a chain of log intent items, the AG header
buffer locks will cycle during a transaction roll to get from one intent
item to the next in a chain. Although scrub takes all AG header buffer
locks, this isn't sufficient to guard against scrub checking an AG while
that writer thread is in the middle of finishing a chain because there's
no higher level locking primitive guarding allocation groups.
When there's a collision, cross-referencing between data structures
(e.g. rmapbt and refcountbt) yields false corruption events; if repair
is running, this results in incorrect repairs, which is catastrophic.
Fix this by adding to the perag structure the count of active intents
and make scrub wait until it has both AG header buffer locks and the
intent counter reaches zero.
One quirk of the drain code is that deferred bmap updates also bump and
drop the intent counter. A fundamental decision made during the design
phase of the reverse mapping feature is that updates to the rmapbt
records are always made by the same code that updates the primary
metadata. In other words, callers of bmapi functions expect that the
bmapi functions will queue deferred rmap updates.
Some parts of the reflink code queue deferred refcount (CUI) and bmap
(BUI) updates in the same head transaction, but the deferred work
manager completely finishes the CUI before the BUI work is started. As
a result, the CUI drops the intent count long before the deferred rmap
(RUI) update even has a chance to bump the intent count. The only way
to keep the intent count elevated between the CUI and RUI is for the BUI
to bump the counter until the RUI has been created.
A second quirk of the intent drain code is that deferred work items must
increment the intent counter as soon as the work item is added to the
transaction. When a BUI completes and queues an RUI, the RUI must
increment the counter before the BUI decrements it. The only way to
accomplish this is to require that the counter be bumped as soon as the
deferred work item is created in memory.
In the next patches we'll improve on this facility, but this patch
provides the basic functionality.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
2023-04-12 01:59:58 +00:00
|
|
|
xfs_perag_intent_put(bi->bi_pag);
|
2023-04-12 01:59:53 +00:00
|
|
|
}
|
|
|
|
|
2019-06-29 02:29:42 +00:00
|
|
|
/* Process a deferred rmap update. */
|
|
|
|
STATIC int
|
|
|
|
xfs_bmap_update_finish_item(
|
|
|
|
struct xfs_trans *tp,
|
2020-04-30 19:52:22 +00:00
|
|
|
struct xfs_log_item *done,
|
2019-06-29 02:29:42 +00:00
|
|
|
struct list_head *item,
|
2020-04-30 19:52:22 +00:00
|
|
|
struct xfs_btree_cur **state)
|
2019-06-29 02:29:42 +00:00
|
|
|
{
|
2023-02-01 17:50:53 +00:00
|
|
|
struct xfs_bmap_intent *bi;
|
2019-06-29 02:29:42 +00:00
|
|
|
int error;
|
|
|
|
|
2023-02-01 17:50:53 +00:00
|
|
|
bi = container_of(item, struct xfs_bmap_intent, bi_list);
|
|
|
|
|
|
|
|
error = xfs_trans_log_finish_bmap_update(tp, BUD_ITEM(done), bi);
|
|
|
|
if (!error && bi->bi_bmap.br_blockcount > 0) {
|
|
|
|
ASSERT(bi->bi_type == XFS_BMAP_UNMAP);
|
2019-06-29 02:29:42 +00:00
|
|
|
return -EAGAIN;
|
|
|
|
}
|
2023-04-12 01:59:53 +00:00
|
|
|
|
|
|
|
xfs_bmap_update_put_group(bi);
|
2023-02-01 17:50:53 +00:00
|
|
|
kmem_cache_free(xfs_bmap_intent_cache, bi);
|
2019-06-29 02:29:42 +00:00
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Abort all pending BUIs. */
|
|
|
|
STATIC void
|
|
|
|
xfs_bmap_update_abort_intent(
|
2020-04-30 19:52:21 +00:00
|
|
|
struct xfs_log_item *intent)
|
2019-06-29 02:29:42 +00:00
|
|
|
{
|
2020-04-30 19:52:21 +00:00
|
|
|
xfs_bui_release(BUI_ITEM(intent));
|
2019-06-29 02:29:42 +00:00
|
|
|
}
|
|
|
|
|
2023-04-12 01:59:53 +00:00
|
|
|
/* Cancel a deferred bmap update. */
|
2019-06-29 02:29:42 +00:00
|
|
|
STATIC void
|
|
|
|
xfs_bmap_update_cancel_item(
|
|
|
|
struct list_head *item)
|
|
|
|
{
|
2023-02-01 18:16:01 +00:00
|
|
|
struct xfs_bmap_intent *bi;
|
2019-06-29 02:29:42 +00:00
|
|
|
|
2023-02-01 18:16:01 +00:00
|
|
|
bi = container_of(item, struct xfs_bmap_intent, bi_list);
|
2023-04-12 01:59:53 +00:00
|
|
|
|
|
|
|
xfs_bmap_update_put_group(bi);
|
2023-02-01 18:16:01 +00:00
|
|
|
kmem_cache_free(xfs_bmap_intent_cache, bi);
|
2019-06-29 02:29:42 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
const struct xfs_defer_op_type xfs_bmap_update_defer_type = {
|
|
|
|
.max_items = XFS_BUI_MAX_FAST_EXTENTS,
|
|
|
|
.create_intent = xfs_bmap_update_create_intent,
|
|
|
|
.abort_intent = xfs_bmap_update_abort_intent,
|
|
|
|
.create_done = xfs_bmap_update_create_done,
|
|
|
|
.finish_item = xfs_bmap_update_finish_item,
|
|
|
|
.cancel_item = xfs_bmap_update_cancel_item,
|
|
|
|
};
|
|
|
|
|
2020-11-30 00:33:35 +00:00
|
|
|
/* Is this recovered BUI ok? */
|
|
|
|
static inline bool
|
|
|
|
xfs_bui_validate(
|
|
|
|
struct xfs_mount *mp,
|
|
|
|
struct xfs_bui_log_item *buip)
|
|
|
|
{
|
2023-02-01 18:16:01 +00:00
|
|
|
struct xfs_map_extent *map;
|
2020-11-30 00:33:35 +00:00
|
|
|
|
|
|
|
/* Only one mapping operation per BUI... */
|
|
|
|
if (buip->bui_format.bui_nextents != XFS_BUI_MAX_FAST_EXTENTS)
|
|
|
|
return false;
|
|
|
|
|
2023-02-01 18:16:01 +00:00
|
|
|
map = &buip->bui_format.bui_extents[0];
|
2020-11-30 00:33:35 +00:00
|
|
|
|
2023-02-01 18:16:01 +00:00
|
|
|
if (map->me_flags & ~XFS_BMAP_EXTENT_FLAGS)
|
2020-11-30 00:33:35 +00:00
|
|
|
return false;
|
|
|
|
|
2023-02-01 18:16:01 +00:00
|
|
|
switch (map->me_flags & XFS_BMAP_EXTENT_TYPE_MASK) {
|
2020-11-30 00:33:35 +00:00
|
|
|
case XFS_BMAP_MAP:
|
|
|
|
case XFS_BMAP_UNMAP:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2023-02-01 18:16:01 +00:00
|
|
|
if (!xfs_verify_ino(mp, map->me_owner))
|
2020-11-30 00:33:36 +00:00
|
|
|
return false;
|
|
|
|
|
2023-02-01 18:16:01 +00:00
|
|
|
if (!xfs_verify_fileext(mp, map->me_startoff, map->me_len))
|
2020-11-30 00:33:36 +00:00
|
|
|
return false;
|
|
|
|
|
2023-02-01 18:16:01 +00:00
|
|
|
return xfs_verify_fsbext(mp, map->me_startblock, map->me_len);
|
2020-11-30 00:33:35 +00:00
|
|
|
}
|
|
|
|
|
2016-10-03 16:11:26 +00:00
|
|
|
/*
|
|
|
|
* Process a bmap update intent item that was recovered from the log.
|
|
|
|
* We need to update some inode's bmbt.
|
|
|
|
*/
|
2020-05-01 23:00:52 +00:00
|
|
|
STATIC int
|
2020-05-01 23:00:55 +00:00
|
|
|
xfs_bui_item_recover(
|
|
|
|
struct xfs_log_item *lip,
|
xfs: proper replay of deferred ops queued during log recovery
When we replay unfinished intent items that have been recovered from the
log, it's possible that the replay will cause the creation of more
deferred work items. As outlined in commit 509955823cc9c ("xfs: log
recovery should replay deferred ops in order"), later work items have an
implicit ordering dependency on earlier work items. Therefore, recovery
must replay the items (both recovered and created) in the same order
that they would have been during normal operation.
For log recovery, we enforce this ordering by using an empty transaction
to collect deferred ops that get created in the process of recovering a
log intent item to prevent them from being committed before the rest of
the recovered intent items. After we finish committing all the
recovered log items, we allocate a transaction with an enormous block
reservation, splice our huge list of created deferred ops into that
transaction, and commit it, thereby finishing all those ops.
This is /really/ hokey -- it's the one place in XFS where we allow
nested transactions; the splicing of the defer ops list is is inelegant
and has to be done twice per recovery function; and the broken way we
handle inode pointers and block reservations cause subtle use-after-free
and allocator problems that will be fixed by this patch and the two
patches after it.
Therefore, replace the hokey empty transaction with a structure designed
to capture each chain of deferred ops that are created as part of
recovering a single unfinished log intent. Finally, refactor the loop
that replays those chains to do so using one transaction per chain.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2020-09-26 00:39:37 +00:00
|
|
|
struct list_head *capture_list)
|
2016-10-03 16:11:26 +00:00
|
|
|
{
|
2023-02-01 17:50:53 +00:00
|
|
|
struct xfs_bmap_intent fake = { };
|
2020-05-01 23:00:55 +00:00
|
|
|
struct xfs_bui_log_item *buip = BUI_ITEM(lip);
|
|
|
|
struct xfs_trans *tp;
|
|
|
|
struct xfs_inode *ip = NULL;
|
2022-03-17 16:09:12 +00:00
|
|
|
struct xfs_mount *mp = lip->li_log->l_mp;
|
2023-02-01 17:50:53 +00:00
|
|
|
struct xfs_map_extent *map;
|
2020-05-01 23:00:55 +00:00
|
|
|
struct xfs_bud_log_item *budp;
|
2021-01-23 00:48:11 +00:00
|
|
|
int iext_delta;
|
2020-05-01 23:00:55 +00:00
|
|
|
int error = 0;
|
2016-10-03 16:11:26 +00:00
|
|
|
|
2020-11-30 00:33:35 +00:00
|
|
|
if (!xfs_bui_validate(mp, buip)) {
|
|
|
|
XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp,
|
|
|
|
&buip->bui_format, sizeof(buip->bui_format));
|
2019-11-06 17:17:43 +00:00
|
|
|
return -EFSCORRUPTED;
|
2020-11-30 00:33:35 +00:00
|
|
|
}
|
2016-10-03 16:11:26 +00:00
|
|
|
|
2023-02-01 17:50:53 +00:00
|
|
|
map = &buip->bui_format.bui_extents[0];
|
|
|
|
fake.bi_whichfork = (map->me_flags & XFS_BMAP_EXTENT_ATTR_FORK) ?
|
2020-09-26 00:39:50 +00:00
|
|
|
XFS_ATTR_FORK : XFS_DATA_FORK;
|
2023-02-01 17:50:53 +00:00
|
|
|
fake.bi_type = map->me_flags & XFS_BMAP_EXTENT_TYPE_MASK;
|
2016-10-03 16:11:26 +00:00
|
|
|
|
2023-02-01 17:50:53 +00:00
|
|
|
error = xlog_recover_iget(mp, map->me_owner, &ip);
|
2016-10-03 16:11:28 +00:00
|
|
|
if (error)
|
2020-09-26 00:39:50 +00:00
|
|
|
return error;
|
2016-10-03 16:11:28 +00:00
|
|
|
|
2020-09-26 00:39:50 +00:00
|
|
|
/* Allocate transaction and do the work. */
|
|
|
|
error = xfs_trans_alloc(mp, &M_RES(mp)->tr_itruncate,
|
|
|
|
XFS_EXTENTADD_SPACE_RES(mp, XFS_DATA_FORK), 0, 0, &tp);
|
|
|
|
if (error)
|
|
|
|
goto err_rele;
|
|
|
|
|
|
|
|
budp = xfs_trans_get_bud(tp, buip);
|
|
|
|
xfs_ilock(ip, XFS_ILOCK_EXCL);
|
2016-10-03 16:11:28 +00:00
|
|
|
xfs_trans_ijoin(tp, ip, 0);
|
|
|
|
|
2023-02-01 17:50:53 +00:00
|
|
|
if (fake.bi_type == XFS_BMAP_MAP)
|
2021-01-23 00:48:11 +00:00
|
|
|
iext_delta = XFS_IEXT_ADD_NOSPLIT_CNT;
|
|
|
|
else
|
|
|
|
iext_delta = XFS_IEXT_PUNCH_HOLE_CNT;
|
|
|
|
|
2023-02-01 17:50:53 +00:00
|
|
|
error = xfs_iext_count_may_overflow(ip, fake.bi_whichfork, iext_delta);
|
2022-03-09 07:49:36 +00:00
|
|
|
if (error == -EFBIG)
|
|
|
|
error = xfs_iext_count_upgrade(tp, ip, iext_delta);
|
2021-01-23 00:48:11 +00:00
|
|
|
if (error)
|
|
|
|
goto err_cancel;
|
2021-01-23 00:48:11 +00:00
|
|
|
|
2023-02-01 17:50:53 +00:00
|
|
|
fake.bi_owner = ip;
|
|
|
|
fake.bi_bmap.br_startblock = map->me_startblock;
|
|
|
|
fake.bi_bmap.br_startoff = map->me_startoff;
|
|
|
|
fake.bi_bmap.br_blockcount = map->me_len;
|
|
|
|
fake.bi_bmap.br_state = (map->me_flags & XFS_BMAP_EXTENT_UNWRITTEN) ?
|
|
|
|
XFS_EXT_UNWRITTEN : XFS_EXT_NORM;
|
|
|
|
|
2023-04-12 01:59:53 +00:00
|
|
|
xfs_bmap_update_get_group(mp, &fake);
|
2023-02-01 17:50:53 +00:00
|
|
|
error = xfs_trans_log_finish_bmap_update(tp, budp, &fake);
|
2021-08-06 18:06:35 +00:00
|
|
|
if (error == -EFSCORRUPTED)
|
2023-02-01 17:50:53 +00:00
|
|
|
XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp, map,
|
|
|
|
sizeof(*map));
|
2023-04-12 01:59:53 +00:00
|
|
|
xfs_bmap_update_put_group(&fake);
|
2016-10-03 16:11:28 +00:00
|
|
|
if (error)
|
2020-09-26 00:39:50 +00:00
|
|
|
goto err_cancel;
|
2016-10-03 16:11:28 +00:00
|
|
|
|
2023-02-01 17:50:53 +00:00
|
|
|
if (fake.bi_bmap.br_blockcount > 0) {
|
|
|
|
ASSERT(fake.bi_type == XFS_BMAP_UNMAP);
|
|
|
|
xfs_bmap_unmap_extent(tp, ip, &fake.bi_bmap);
|
2017-06-15 04:25:57 +00:00
|
|
|
}
|
|
|
|
|
2020-09-26 00:39:51 +00:00
|
|
|
/*
|
|
|
|
* Commit transaction, which frees the transaction and saves the inode
|
|
|
|
* for later replay activities.
|
|
|
|
*/
|
2021-09-17 00:28:07 +00:00
|
|
|
error = xfs_defer_ops_capture_and_commit(tp, capture_list);
|
2020-09-26 00:39:50 +00:00
|
|
|
if (error)
|
|
|
|
goto err_unlock;
|
|
|
|
|
2016-10-03 16:11:28 +00:00
|
|
|
xfs_iunlock(ip, XFS_ILOCK_EXCL);
|
2018-07-25 19:52:32 +00:00
|
|
|
xfs_irele(ip);
|
2020-09-26 00:39:50 +00:00
|
|
|
return 0;
|
2016-10-03 16:11:28 +00:00
|
|
|
|
2020-09-26 00:39:50 +00:00
|
|
|
err_cancel:
|
2016-10-03 16:11:28 +00:00
|
|
|
xfs_trans_cancel(tp);
|
2020-09-26 00:39:50 +00:00
|
|
|
err_unlock:
|
|
|
|
xfs_iunlock(ip, XFS_ILOCK_EXCL);
|
|
|
|
err_rele:
|
|
|
|
xfs_irele(ip);
|
2016-10-03 16:11:26 +00:00
|
|
|
return error;
|
|
|
|
}
|
2020-05-01 23:00:45 +00:00
|
|
|
|
2020-05-01 23:00:54 +00:00
|
|
|
STATIC bool
|
|
|
|
xfs_bui_item_match(
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
uint64_t intent_id)
|
|
|
|
{
|
|
|
|
return BUI_ITEM(lip)->bui_format.bui_id == intent_id;
|
|
|
|
}
|
|
|
|
|
xfs: periodically relog deferred intent items
There's a subtle design flaw in the deferred log item code that can lead
to pinning the log tail. Taking up the defer ops chain examples from
the previous commit, we can get trapped in sequences like this:
Caller hands us a transaction t0 with D0-D3 attached. The defer ops
chain will look like the following if the transaction rolls succeed:
t1: D0(t0), D1(t0), D2(t0), D3(t0)
t2: d4(t1), d5(t1), D1(t0), D2(t0), D3(t0)
t3: d5(t1), D1(t0), D2(t0), D3(t0)
...
t9: d9(t7), D3(t0)
t10: D3(t0)
t11: d10(t10), d11(t10)
t12: d11(t10)
In transaction 9, we finish d9 and try to roll to t10 while holding onto
an intent item for D3 that we logged in t0.
The previous commit changed the order in which we place new defer ops in
the defer ops processing chain to reduce the maximum chain length. Now
make xfs_defer_finish_noroll capable of relogging the entire chain
periodically so that we can always move the log tail forward. Most
chains will never get relogged, except for operations that generate very
long chains (large extents containing many blocks with different sharing
levels) or are on filesystems with small logs and a lot of ongoing
metadata updates.
Callers are now required to ensure that the transaction reservation is
large enough to handle logging done items and new intent items for the
maximum possible chain length. Most callers are careful to keep the
chain lengths low, so the overhead should be minimal.
The decision to relog an intent item is made based on whether the intent
was logged in a previous checkpoint, since there's no point in relogging
an intent into the same checkpoint.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
2020-09-27 23:18:13 +00:00
|
|
|
/* Relog an intent item to push the log tail forward. */
|
|
|
|
static struct xfs_log_item *
|
|
|
|
xfs_bui_item_relog(
|
|
|
|
struct xfs_log_item *intent,
|
|
|
|
struct xfs_trans *tp)
|
|
|
|
{
|
|
|
|
struct xfs_bud_log_item *budp;
|
|
|
|
struct xfs_bui_log_item *buip;
|
2023-02-01 18:16:01 +00:00
|
|
|
struct xfs_map_extent *map;
|
xfs: periodically relog deferred intent items
There's a subtle design flaw in the deferred log item code that can lead
to pinning the log tail. Taking up the defer ops chain examples from
the previous commit, we can get trapped in sequences like this:
Caller hands us a transaction t0 with D0-D3 attached. The defer ops
chain will look like the following if the transaction rolls succeed:
t1: D0(t0), D1(t0), D2(t0), D3(t0)
t2: d4(t1), d5(t1), D1(t0), D2(t0), D3(t0)
t3: d5(t1), D1(t0), D2(t0), D3(t0)
...
t9: d9(t7), D3(t0)
t10: D3(t0)
t11: d10(t10), d11(t10)
t12: d11(t10)
In transaction 9, we finish d9 and try to roll to t10 while holding onto
an intent item for D3 that we logged in t0.
The previous commit changed the order in which we place new defer ops in
the defer ops processing chain to reduce the maximum chain length. Now
make xfs_defer_finish_noroll capable of relogging the entire chain
periodically so that we can always move the log tail forward. Most
chains will never get relogged, except for operations that generate very
long chains (large extents containing many blocks with different sharing
levels) or are on filesystems with small logs and a lot of ongoing
metadata updates.
Callers are now required to ensure that the transaction reservation is
large enough to handle logging done items and new intent items for the
maximum possible chain length. Most callers are careful to keep the
chain lengths low, so the overhead should be minimal.
The decision to relog an intent item is made based on whether the intent
was logged in a previous checkpoint, since there's no point in relogging
an intent into the same checkpoint.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
2020-09-27 23:18:13 +00:00
|
|
|
unsigned int count;
|
|
|
|
|
|
|
|
count = BUI_ITEM(intent)->bui_format.bui_nextents;
|
2023-02-01 18:16:01 +00:00
|
|
|
map = BUI_ITEM(intent)->bui_format.bui_extents;
|
xfs: periodically relog deferred intent items
There's a subtle design flaw in the deferred log item code that can lead
to pinning the log tail. Taking up the defer ops chain examples from
the previous commit, we can get trapped in sequences like this:
Caller hands us a transaction t0 with D0-D3 attached. The defer ops
chain will look like the following if the transaction rolls succeed:
t1: D0(t0), D1(t0), D2(t0), D3(t0)
t2: d4(t1), d5(t1), D1(t0), D2(t0), D3(t0)
t3: d5(t1), D1(t0), D2(t0), D3(t0)
...
t9: d9(t7), D3(t0)
t10: D3(t0)
t11: d10(t10), d11(t10)
t12: d11(t10)
In transaction 9, we finish d9 and try to roll to t10 while holding onto
an intent item for D3 that we logged in t0.
The previous commit changed the order in which we place new defer ops in
the defer ops processing chain to reduce the maximum chain length. Now
make xfs_defer_finish_noroll capable of relogging the entire chain
periodically so that we can always move the log tail forward. Most
chains will never get relogged, except for operations that generate very
long chains (large extents containing many blocks with different sharing
levels) or are on filesystems with small logs and a lot of ongoing
metadata updates.
Callers are now required to ensure that the transaction reservation is
large enough to handle logging done items and new intent items for the
maximum possible chain length. Most callers are careful to keep the
chain lengths low, so the overhead should be minimal.
The decision to relog an intent item is made based on whether the intent
was logged in a previous checkpoint, since there's no point in relogging
an intent into the same checkpoint.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
2020-09-27 23:18:13 +00:00
|
|
|
|
|
|
|
tp->t_flags |= XFS_TRANS_DIRTY;
|
|
|
|
budp = xfs_trans_get_bud(tp, BUI_ITEM(intent));
|
|
|
|
set_bit(XFS_LI_DIRTY, &budp->bud_item.li_flags);
|
|
|
|
|
|
|
|
buip = xfs_bui_init(tp->t_mountp);
|
2023-02-01 18:16:01 +00:00
|
|
|
memcpy(buip->bui_format.bui_extents, map, count * sizeof(*map));
|
xfs: periodically relog deferred intent items
There's a subtle design flaw in the deferred log item code that can lead
to pinning the log tail. Taking up the defer ops chain examples from
the previous commit, we can get trapped in sequences like this:
Caller hands us a transaction t0 with D0-D3 attached. The defer ops
chain will look like the following if the transaction rolls succeed:
t1: D0(t0), D1(t0), D2(t0), D3(t0)
t2: d4(t1), d5(t1), D1(t0), D2(t0), D3(t0)
t3: d5(t1), D1(t0), D2(t0), D3(t0)
...
t9: d9(t7), D3(t0)
t10: D3(t0)
t11: d10(t10), d11(t10)
t12: d11(t10)
In transaction 9, we finish d9 and try to roll to t10 while holding onto
an intent item for D3 that we logged in t0.
The previous commit changed the order in which we place new defer ops in
the defer ops processing chain to reduce the maximum chain length. Now
make xfs_defer_finish_noroll capable of relogging the entire chain
periodically so that we can always move the log tail forward. Most
chains will never get relogged, except for operations that generate very
long chains (large extents containing many blocks with different sharing
levels) or are on filesystems with small logs and a lot of ongoing
metadata updates.
Callers are now required to ensure that the transaction reservation is
large enough to handle logging done items and new intent items for the
maximum possible chain length. Most callers are careful to keep the
chain lengths low, so the overhead should be minimal.
The decision to relog an intent item is made based on whether the intent
was logged in a previous checkpoint, since there's no point in relogging
an intent into the same checkpoint.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
2020-09-27 23:18:13 +00:00
|
|
|
atomic_set(&buip->bui_next_extent, count);
|
|
|
|
xfs_trans_add_item(tp, &buip->bui_item);
|
|
|
|
set_bit(XFS_LI_DIRTY, &buip->bui_item.li_flags);
|
|
|
|
return &buip->bui_item;
|
|
|
|
}
|
|
|
|
|
2020-05-01 23:00:52 +00:00
|
|
|
static const struct xfs_item_ops xfs_bui_item_ops = {
|
2022-05-04 01:46:09 +00:00
|
|
|
.flags = XFS_ITEM_INTENT,
|
2020-05-01 23:00:52 +00:00
|
|
|
.iop_size = xfs_bui_item_size,
|
|
|
|
.iop_format = xfs_bui_item_format,
|
|
|
|
.iop_unpin = xfs_bui_item_unpin,
|
|
|
|
.iop_release = xfs_bui_item_release,
|
|
|
|
.iop_recover = xfs_bui_item_recover,
|
2020-05-01 23:00:54 +00:00
|
|
|
.iop_match = xfs_bui_item_match,
|
xfs: periodically relog deferred intent items
There's a subtle design flaw in the deferred log item code that can lead
to pinning the log tail. Taking up the defer ops chain examples from
the previous commit, we can get trapped in sequences like this:
Caller hands us a transaction t0 with D0-D3 attached. The defer ops
chain will look like the following if the transaction rolls succeed:
t1: D0(t0), D1(t0), D2(t0), D3(t0)
t2: d4(t1), d5(t1), D1(t0), D2(t0), D3(t0)
t3: d5(t1), D1(t0), D2(t0), D3(t0)
...
t9: d9(t7), D3(t0)
t10: D3(t0)
t11: d10(t10), d11(t10)
t12: d11(t10)
In transaction 9, we finish d9 and try to roll to t10 while holding onto
an intent item for D3 that we logged in t0.
The previous commit changed the order in which we place new defer ops in
the defer ops processing chain to reduce the maximum chain length. Now
make xfs_defer_finish_noroll capable of relogging the entire chain
periodically so that we can always move the log tail forward. Most
chains will never get relogged, except for operations that generate very
long chains (large extents containing many blocks with different sharing
levels) or are on filesystems with small logs and a lot of ongoing
metadata updates.
Callers are now required to ensure that the transaction reservation is
large enough to handle logging done items and new intent items for the
maximum possible chain length. Most callers are careful to keep the
chain lengths low, so the overhead should be minimal.
The decision to relog an intent item is made based on whether the intent
was logged in a previous checkpoint, since there's no point in relogging
an intent into the same checkpoint.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
2020-09-27 23:18:13 +00:00
|
|
|
.iop_relog = xfs_bui_item_relog,
|
2020-05-01 23:00:52 +00:00
|
|
|
};
|
|
|
|
|
2022-10-20 23:17:41 +00:00
|
|
|
static inline void
|
2020-05-01 23:00:50 +00:00
|
|
|
xfs_bui_copy_format(
|
2022-10-20 23:17:41 +00:00
|
|
|
struct xfs_bui_log_format *dst,
|
|
|
|
const struct xfs_bui_log_format *src)
|
2020-05-01 23:00:50 +00:00
|
|
|
{
|
2022-10-20 23:17:41 +00:00
|
|
|
unsigned int i;
|
2020-05-01 23:00:50 +00:00
|
|
|
|
2022-10-20 23:17:41 +00:00
|
|
|
memcpy(dst, src, offsetof(struct xfs_bui_log_format, bui_extents));
|
2020-05-01 23:00:50 +00:00
|
|
|
|
2022-10-20 23:17:41 +00:00
|
|
|
for (i = 0; i < src->bui_nextents; i++)
|
|
|
|
memcpy(&dst->bui_extents[i], &src->bui_extents[i],
|
|
|
|
sizeof(struct xfs_map_extent));
|
2020-05-01 23:00:50 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This routine is called to create an in-core extent bmap update
|
|
|
|
* item from the bui format structure which was logged on disk.
|
|
|
|
* It allocates an in-core bui, copies the extents from the format
|
|
|
|
* structure into it, and adds the bui to the AIL with the given
|
|
|
|
* LSN.
|
|
|
|
*/
|
|
|
|
STATIC int
|
|
|
|
xlog_recover_bui_commit_pass2(
|
|
|
|
struct xlog *log,
|
|
|
|
struct list_head *buffer_list,
|
|
|
|
struct xlog_recover_item *item,
|
|
|
|
xfs_lsn_t lsn)
|
|
|
|
{
|
|
|
|
struct xfs_mount *mp = log->l_mp;
|
|
|
|
struct xfs_bui_log_item *buip;
|
|
|
|
struct xfs_bui_log_format *bui_formatp;
|
2022-10-20 23:17:41 +00:00
|
|
|
size_t len;
|
2020-05-01 23:00:50 +00:00
|
|
|
|
|
|
|
bui_formatp = item->ri_buf[0].i_addr;
|
|
|
|
|
2022-10-20 23:17:41 +00:00
|
|
|
if (item->ri_buf[0].i_len < xfs_bui_log_format_sizeof(0)) {
|
2022-10-25 22:07:14 +00:00
|
|
|
XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp,
|
|
|
|
item->ri_buf[0].i_addr, item->ri_buf[0].i_len);
|
2022-10-20 23:17:41 +00:00
|
|
|
return -EFSCORRUPTED;
|
|
|
|
}
|
|
|
|
|
2020-05-01 23:00:50 +00:00
|
|
|
if (bui_formatp->bui_nextents != XFS_BUI_MAX_FAST_EXTENTS) {
|
2022-10-25 22:07:14 +00:00
|
|
|
XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp,
|
|
|
|
item->ri_buf[0].i_addr, item->ri_buf[0].i_len);
|
2020-05-01 23:00:50 +00:00
|
|
|
return -EFSCORRUPTED;
|
|
|
|
}
|
2022-10-20 23:17:41 +00:00
|
|
|
|
|
|
|
len = xfs_bui_log_format_sizeof(bui_formatp->bui_nextents);
|
|
|
|
if (item->ri_buf[0].i_len != len) {
|
2022-10-25 22:07:14 +00:00
|
|
|
XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp,
|
|
|
|
item->ri_buf[0].i_addr, item->ri_buf[0].i_len);
|
2022-10-20 23:17:41 +00:00
|
|
|
return -EFSCORRUPTED;
|
2020-05-01 23:00:50 +00:00
|
|
|
}
|
2022-10-20 23:17:41 +00:00
|
|
|
|
|
|
|
buip = xfs_bui_init(mp);
|
|
|
|
xfs_bui_copy_format(&buip->bui_format, bui_formatp);
|
2020-05-01 23:00:50 +00:00
|
|
|
atomic_set(&buip->bui_next_extent, bui_formatp->bui_nextents);
|
|
|
|
/*
|
2020-05-01 23:00:54 +00:00
|
|
|
* Insert the intent into the AIL directly and drop one reference so
|
|
|
|
* that finishing or canceling the work will drop the other.
|
2020-05-01 23:00:50 +00:00
|
|
|
*/
|
2020-05-01 23:00:54 +00:00
|
|
|
xfs_trans_ail_insert(log->l_ailp, &buip->bui_item, lsn);
|
2020-05-01 23:00:50 +00:00
|
|
|
xfs_bui_release(buip);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-05-01 23:00:45 +00:00
|
|
|
const struct xlog_recover_item_ops xlog_bui_item_ops = {
|
|
|
|
.item_type = XFS_LI_BUI,
|
2020-05-01 23:00:50 +00:00
|
|
|
.commit_pass2 = xlog_recover_bui_commit_pass2,
|
2020-05-01 23:00:45 +00:00
|
|
|
};
|
|
|
|
|
2020-05-01 23:00:50 +00:00
|
|
|
/*
|
|
|
|
* This routine is called when an BUD format structure is found in a committed
|
|
|
|
* transaction in the log. Its purpose is to cancel the corresponding BUI if it
|
|
|
|
* was still in the log. To do this it searches the AIL for the BUI with an id
|
|
|
|
* equal to that in the BUD format structure. If we find it we drop the BUD
|
|
|
|
* reference, which removes the BUI from the AIL and frees it.
|
|
|
|
*/
|
|
|
|
STATIC int
|
|
|
|
xlog_recover_bud_commit_pass2(
|
|
|
|
struct xlog *log,
|
|
|
|
struct list_head *buffer_list,
|
|
|
|
struct xlog_recover_item *item,
|
|
|
|
xfs_lsn_t lsn)
|
|
|
|
{
|
|
|
|
struct xfs_bud_log_format *bud_formatp;
|
|
|
|
|
|
|
|
bud_formatp = item->ri_buf[0].i_addr;
|
|
|
|
if (item->ri_buf[0].i_len != sizeof(struct xfs_bud_log_format)) {
|
2022-10-25 22:07:14 +00:00
|
|
|
XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, log->l_mp,
|
|
|
|
item->ri_buf[0].i_addr, item->ri_buf[0].i_len);
|
2020-05-01 23:00:50 +00:00
|
|
|
return -EFSCORRUPTED;
|
|
|
|
}
|
|
|
|
|
2020-05-01 23:00:54 +00:00
|
|
|
xlog_recover_release_intent(log, XFS_LI_BUI, bud_formatp->bud_bui_id);
|
2020-05-01 23:00:50 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-05-01 23:00:45 +00:00
|
|
|
const struct xlog_recover_item_ops xlog_bud_item_ops = {
|
|
|
|
.item_type = XFS_LI_BUD,
|
2020-05-01 23:00:50 +00:00
|
|
|
.commit_pass2 = xlog_recover_bud_commit_pass2,
|
2020-05-01 23:00:45 +00:00
|
|
|
};
|