xfs: define an in-memory btree for storing refcount bag info during repairs
Create a new in-memory btree type so that we can store refcount bag info
in a much more memory-efficient and performant format. Recall that the
refcount recordset regenerator computes the new recordset from browsing
the rmap records. Let's say that the rmap records are:
{agbno: 10, length: 40, ...}
{agbno: 11, length: 3, ...}
{agbno: 12, length: 20, ...}
{agbno: 15, length: 1, ...}
It is convenient to have a data structure that could quickly tell us the
refcount for an arbitrary agbno without wasting memory. An array or a
list could do that pretty easily. List suck because of the pointer
overhead. xfarrays are a lot more compact, but we want to minimize
sparse holes in the xfarray to constrain memory usage. Maintaining any
kind of record order isn't needed for correctness, so I created the
"rcbag", which is shorthand for an unordered list of (excerpted) reverse
mappings.
So we add the first rmap to the rcbag, and it looks like:
0: {agbno: 10, length: 40}
The refcount for agbno 10 is 1. Then we move on to block 11, so we add
the second rmap:
0: {agbno: 10, length: 40}
1: {agbno: 11, length: 3}
The refcount for agbno 11 is 2. We move on to block 12, so we add the
third:
0: {agbno: 10, length: 40}
1: {agbno: 11, length: 3}
2: {agbno: 12, length: 20}
The refcount for agbno 12 and 13 is 3. We move on to block 14, and
remove the second rmap:
0: {agbno: 10, length: 40}
1: NULL
2: {agbno: 12, length: 20}
The refcount for agbno 14 is 2. We move on to block 15, and add the
last rmap. But we don't care where it is and we don't want to expand
the array so we put it in slot 1:
0: {agbno: 10, length: 40}
1: {agbno: 15, length: 1}
2: {agbno: 12, length: 20}
The refcount for block 15 is 3. Notice how order doesn't matter in this
list? That's why repair uses an unordered list, or "bag". The data
structure is not a set because it does not guarantee uniqueness.
That said, adding and removing specific items is now an O(n) operation
because we have no idea where that item might be in the list. Overall,
the runtime is O(n^2) which is bad.
I realized that I could easily refactor the btree code and reimplement
the refcount bag with an xfbtree. Adding and removing is now O(log2 n),
so the runtime is at least O(n log2 n), which is much faster. In the
end, the rcbag becomes a sorted list, but that's merely a detail of the
implementation. The repair code doesn't care.
(Note: That horrible xfs_db bmap_inflate command can be used to exercise
this sort of rcbag insanity by cranking up refcounts quickly.)
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2024-02-23 04:43:40 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
|
/*
|
|
|
|
|
* Copyright (c) 2022-2024 Oracle. All Rights Reserved.
|
|
|
|
|
* Author: Darrick J. Wong <djwong@kernel.org>
|
|
|
|
|
*/
|
|
|
|
|
#ifndef __XFS_SCRUB_RCBAG_BTREE_H__
|
|
|
|
|
#define __XFS_SCRUB_RCBAG_BTREE_H__
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_XFS_BTREE_IN_MEM
|
|
|
|
|
|
|
|
|
|
struct xfs_buf;
|
|
|
|
|
struct xfs_btree_cur;
|
|
|
|
|
struct xfs_mount;
|
|
|
|
|
|
|
|
|
|
#define RCBAG_MAGIC 0x74826671 /* 'JRBG' */
|
|
|
|
|
|
|
|
|
|
struct rcbag_key {
|
|
|
|
|
uint32_t rbg_startblock;
|
|
|
|
|
uint32_t rbg_blockcount;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct rcbag_rec {
|
|
|
|
|
uint32_t rbg_startblock;
|
|
|
|
|
uint32_t rbg_blockcount;
|
|
|
|
|
uint64_t rbg_refcount;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
typedef __be64 rcbag_ptr_t;
|
|
|
|
|
|
|
|
|
|
/* reflinks only exist on crc enabled filesystems */
|
|
|
|
|
#define RCBAG_BLOCK_LEN XFS_BTREE_LBLOCK_CRC_LEN
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Record, key, and pointer address macros for btree blocks.
|
|
|
|
|
*
|
|
|
|
|
* (note that some of these may appear unused, but they are used in userspace)
|
|
|
|
|
*/
|
|
|
|
|
#define RCBAG_REC_ADDR(block, index) \
|
|
|
|
|
((struct rcbag_rec *) \
|
|
|
|
|
((char *)(block) + RCBAG_BLOCK_LEN + \
|
|
|
|
|
(((index) - 1) * sizeof(struct rcbag_rec))))
|
|
|
|
|
|
|
|
|
|
#define RCBAG_KEY_ADDR(block, index) \
|
|
|
|
|
((struct rcbag_key *) \
|
|
|
|
|
((char *)(block) + RCBAG_BLOCK_LEN + \
|
|
|
|
|
((index) - 1) * sizeof(struct rcbag_key)))
|
|
|
|
|
|
|
|
|
|
#define RCBAG_PTR_ADDR(block, index, maxrecs) \
|
|
|
|
|
((rcbag_ptr_t *) \
|
|
|
|
|
((char *)(block) + RCBAG_BLOCK_LEN + \
|
|
|
|
|
(maxrecs) * sizeof(struct rcbag_key) + \
|
|
|
|
|
((index) - 1) * sizeof(rcbag_ptr_t)))
|
|
|
|
|
|
|
|
|
|
unsigned int rcbagbt_maxrecs(struct xfs_mount *mp, unsigned int blocklen,
|
|
|
|
|
bool leaf);
|
|
|
|
|
|
|
|
|
|
unsigned long long rcbagbt_calc_size(unsigned long long nr_records);
|
|
|
|
|
|
|
|
|
|
unsigned int rcbagbt_maxlevels_possible(void);
|
|
|
|
|
|
|
|
|
|
int __init rcbagbt_init_cur_cache(void);
|
|
|
|
|
void rcbagbt_destroy_cur_cache(void);
|
|
|
|
|
|
|
|
|
|
struct xfs_btree_cur *rcbagbt_mem_cursor(struct xfs_mount *mp,
|
|
|
|
|
struct xfs_trans *tp, struct xfbtree *xfbtree);
|
|
|
|
|
int rcbagbt_mem_init(struct xfs_mount *mp, struct xfbtree *xfbtree,
|
|
|
|
|
struct xfs_buftarg *btp);
|
|
|
|
|
|
2024-02-23 04:43:41 +08:00
|
|
|
int rcbagbt_lookup_eq(struct xfs_btree_cur *cur,
|
|
|
|
|
const struct xfs_rmap_irec *rmap, int *success);
|
|
|
|
|
int rcbagbt_get_rec(struct xfs_btree_cur *cur, struct rcbag_rec *rec, int *has);
|
|
|
|
|
int rcbagbt_update(struct xfs_btree_cur *cur, const struct rcbag_rec *rec);
|
|
|
|
|
int rcbagbt_insert(struct xfs_btree_cur *cur, const struct rcbag_rec *rec,
|
|
|
|
|
int *success);
|
|
|
|
|
|
xfs: define an in-memory btree for storing refcount bag info during repairs
Create a new in-memory btree type so that we can store refcount bag info
in a much more memory-efficient and performant format. Recall that the
refcount recordset regenerator computes the new recordset from browsing
the rmap records. Let's say that the rmap records are:
{agbno: 10, length: 40, ...}
{agbno: 11, length: 3, ...}
{agbno: 12, length: 20, ...}
{agbno: 15, length: 1, ...}
It is convenient to have a data structure that could quickly tell us the
refcount for an arbitrary agbno without wasting memory. An array or a
list could do that pretty easily. List suck because of the pointer
overhead. xfarrays are a lot more compact, but we want to minimize
sparse holes in the xfarray to constrain memory usage. Maintaining any
kind of record order isn't needed for correctness, so I created the
"rcbag", which is shorthand for an unordered list of (excerpted) reverse
mappings.
So we add the first rmap to the rcbag, and it looks like:
0: {agbno: 10, length: 40}
The refcount for agbno 10 is 1. Then we move on to block 11, so we add
the second rmap:
0: {agbno: 10, length: 40}
1: {agbno: 11, length: 3}
The refcount for agbno 11 is 2. We move on to block 12, so we add the
third:
0: {agbno: 10, length: 40}
1: {agbno: 11, length: 3}
2: {agbno: 12, length: 20}
The refcount for agbno 12 and 13 is 3. We move on to block 14, and
remove the second rmap:
0: {agbno: 10, length: 40}
1: NULL
2: {agbno: 12, length: 20}
The refcount for agbno 14 is 2. We move on to block 15, and add the
last rmap. But we don't care where it is and we don't want to expand
the array so we put it in slot 1:
0: {agbno: 10, length: 40}
1: {agbno: 15, length: 1}
2: {agbno: 12, length: 20}
The refcount for block 15 is 3. Notice how order doesn't matter in this
list? That's why repair uses an unordered list, or "bag". The data
structure is not a set because it does not guarantee uniqueness.
That said, adding and removing specific items is now an O(n) operation
because we have no idea where that item might be in the list. Overall,
the runtime is O(n^2) which is bad.
I realized that I could easily refactor the btree code and reimplement
the refcount bag with an xfbtree. Adding and removing is now O(log2 n),
so the runtime is at least O(n log2 n), which is much faster. In the
end, the rcbag becomes a sorted list, but that's merely a detail of the
implementation. The repair code doesn't care.
(Note: That horrible xfs_db bmap_inflate command can be used to exercise
this sort of rcbag insanity by cranking up refcounts quickly.)
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2024-02-23 04:43:40 +08:00
|
|
|
#else
|
|
|
|
|
# define rcbagbt_init_cur_cache() 0
|
|
|
|
|
# define rcbagbt_destroy_cur_cache() ((void)0)
|
|
|
|
|
#endif /* CONFIG_XFS_BTREE_IN_MEM */
|
|
|
|
|
|
|
|
|
|
#endif /* __XFS_SCRUB_RCBAG_BTREE_H__ */
|