2018-06-06 10:42:14 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2011-01-07 21:02:04 +08:00
|
|
|
/*
|
2023-10-04 06:24:02 +08:00
|
|
|
* Copyright (C) 2010, 2023 Red Hat, Inc.
|
2011-01-07 21:02:04 +08:00
|
|
|
* All Rights Reserved.
|
|
|
|
*/
|
|
|
|
#include "xfs.h"
|
2019-06-29 10:25:35 +08:00
|
|
|
#include "xfs_shared.h"
|
2013-08-12 18:49:26 +08:00
|
|
|
#include "xfs_format.h"
|
2013-10-23 07:50:10 +08:00
|
|
|
#include "xfs_log_format.h"
|
|
|
|
#include "xfs_trans_resv.h"
|
2024-01-16 06:59:44 +08:00
|
|
|
#include "xfs_trans.h"
|
2011-01-07 21:02:04 +08:00
|
|
|
#include "xfs_mount.h"
|
2013-10-23 07:51:50 +08:00
|
|
|
#include "xfs_btree.h"
|
|
|
|
#include "xfs_alloc_btree.h"
|
2011-01-07 21:02:04 +08:00
|
|
|
#include "xfs_alloc.h"
|
2019-11-07 09:19:33 +08:00
|
|
|
#include "xfs_discard.h"
|
2011-01-07 21:02:04 +08:00
|
|
|
#include "xfs_error.h"
|
2012-04-29 18:39:43 +08:00
|
|
|
#include "xfs_extent_busy.h"
|
2011-01-07 21:02:04 +08:00
|
|
|
#include "xfs_trace.h"
|
2013-10-23 07:50:10 +08:00
|
|
|
#include "xfs_log.h"
|
2021-06-02 08:48:24 +08:00
|
|
|
#include "xfs_ag.h"
|
2024-02-23 04:32:55 +08:00
|
|
|
#include "xfs_health.h"
|
2011-01-07 21:02:04 +08:00
|
|
|
|
2023-10-04 06:24:52 +08:00
|
|
|
/*
|
|
|
|
* Notes on an efficient, low latency fstrim algorithm
|
|
|
|
*
|
|
|
|
* We need to walk the filesystem free space and issue discards on the free
|
|
|
|
* space that meet the search criteria (size and location). We cannot issue
|
|
|
|
* discards on extents that might be in use, or are so recently in use they are
|
|
|
|
* still marked as busy. To serialise against extent state changes whilst we are
|
|
|
|
* gathering extents to trim, we must hold the AGF lock to lock out other
|
|
|
|
* allocations and extent free operations that might change extent state.
|
|
|
|
*
|
|
|
|
* However, we cannot just hold the AGF for the entire AG free space walk whilst
|
|
|
|
* we issue discards on each free space that is found. Storage devices can have
|
|
|
|
* extremely slow discard implementations (e.g. ceph RBD) and so walking a
|
|
|
|
* couple of million free extents and issuing synchronous discards on each
|
|
|
|
* extent can take a *long* time. Whilst we are doing this walk, nothing else
|
|
|
|
* can access the AGF, and we can stall transactions and hence the log whilst
|
|
|
|
* modifications wait for the AGF lock to be released. This can lead hung tasks
|
|
|
|
* kicking the hung task timer and rebooting the system. This is bad.
|
|
|
|
*
|
|
|
|
* Hence we need to take a leaf from the bulkstat playbook. It takes the AGI
|
|
|
|
* lock, gathers a range of inode cluster buffers that are allocated, drops the
|
|
|
|
* AGI lock and then reads all the inode cluster buffers and processes them. It
|
|
|
|
* loops doing this, using a cursor to keep track of where it is up to in the AG
|
|
|
|
* for each iteration to restart the INOBT lookup from.
|
|
|
|
*
|
|
|
|
* We can't do this exactly with free space - once we drop the AGF lock, the
|
|
|
|
* state of the free extent is out of our control and we cannot run a discard
|
|
|
|
* safely on it in this situation. Unless, of course, we've marked the free
|
|
|
|
* extent as busy and undergoing a discard operation whilst we held the AGF
|
|
|
|
* locked.
|
|
|
|
*
|
|
|
|
* This is exactly how online discard works - free extents are marked busy when
|
|
|
|
* they are freed, and once the extent free has been committed to the journal,
|
|
|
|
* the busy extent record is marked as "undergoing discard" and the discard is
|
|
|
|
* then issued on the free extent. Once the discard completes, the busy extent
|
|
|
|
* record is removed and the extent is able to be allocated again.
|
|
|
|
*
|
|
|
|
* In the context of fstrim, if we find a free extent we need to discard, we
|
|
|
|
* don't have to discard it immediately. All we need to do it record that free
|
|
|
|
* extent as being busy and under discard, and all the allocation routines will
|
|
|
|
* now avoid trying to allocate it. Hence if we mark the extent as busy under
|
|
|
|
* the AGF lock, we can safely discard it without holding the AGF lock because
|
|
|
|
* nothing will attempt to allocate that free space until the discard completes.
|
|
|
|
*
|
|
|
|
* This also allows us to issue discards asynchronously like we do with online
|
|
|
|
* discard, and so for fast devices fstrim will run much faster as we can have
|
|
|
|
* multiple discard operations in flight at once, as well as pipeline the free
|
|
|
|
* extent search so that it overlaps in flight discard IO.
|
|
|
|
*/
|
|
|
|
|
2023-10-04 06:24:02 +08:00
|
|
|
struct workqueue_struct *xfs_discard_wq;
|
|
|
|
|
|
|
|
static void
|
|
|
|
xfs_discard_endio_work(
|
|
|
|
struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct xfs_busy_extents *extents =
|
|
|
|
container_of(work, struct xfs_busy_extents, endio_work);
|
|
|
|
|
|
|
|
xfs_extent_busy_clear(extents->mount, &extents->extent_list, false);
|
2024-01-16 06:59:43 +08:00
|
|
|
kfree(extents->owner);
|
2023-10-04 06:24:02 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Queue up the actual completion to a thread to avoid IRQ-safe locking for
|
|
|
|
* pagb_lock.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
xfs_discard_endio(
|
|
|
|
struct bio *bio)
|
|
|
|
{
|
|
|
|
struct xfs_busy_extents *extents = bio->bi_private;
|
|
|
|
|
|
|
|
INIT_WORK(&extents->endio_work, xfs_discard_endio_work);
|
|
|
|
queue_work(xfs_discard_wq, &extents->endio_work);
|
|
|
|
bio_put(bio);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Walk the discard list and issue discards on all the busy extents in the
|
|
|
|
* list. We plug and chain the bios so that we only need a single completion
|
|
|
|
* call to clear all the busy extents once the discards are complete.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
xfs_discard_extents(
|
|
|
|
struct xfs_mount *mp,
|
|
|
|
struct xfs_busy_extents *extents)
|
|
|
|
{
|
|
|
|
struct xfs_extent_busy *busyp;
|
|
|
|
struct bio *bio = NULL;
|
|
|
|
struct blk_plug plug;
|
|
|
|
int error = 0;
|
|
|
|
|
|
|
|
blk_start_plug(&plug);
|
|
|
|
list_for_each_entry(busyp, &extents->extent_list, list) {
|
|
|
|
trace_xfs_discard_extent(mp, busyp->agno, busyp->bno,
|
|
|
|
busyp->length);
|
|
|
|
|
|
|
|
error = __blkdev_issue_discard(mp->m_ddev_targp->bt_bdev,
|
|
|
|
XFS_AGB_TO_DADDR(mp, busyp->agno, busyp->bno),
|
|
|
|
XFS_FSB_TO_BB(mp, busyp->length),
|
2024-01-16 06:59:44 +08:00
|
|
|
GFP_KERNEL, &bio);
|
2023-10-04 06:24:02 +08:00
|
|
|
if (error && error != -EOPNOTSUPP) {
|
|
|
|
xfs_info(mp,
|
|
|
|
"discard failed for extent [0x%llx,%u], error %d",
|
|
|
|
(unsigned long long)busyp->bno,
|
|
|
|
busyp->length,
|
|
|
|
error);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (bio) {
|
|
|
|
bio->bi_private = extents;
|
|
|
|
bio->bi_end_io = xfs_discard_endio;
|
|
|
|
submit_bio(bio);
|
|
|
|
} else {
|
|
|
|
xfs_discard_endio_work(&extents->endio_work);
|
|
|
|
}
|
|
|
|
blk_finish_plug(&plug);
|
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
xfs: fix performance problems when fstrimming a subset of a fragmented AG
On a 10TB filesystem where the free space in each AG is heavily
fragmented, I noticed some very high runtimes on a FITRIM call for the
entire filesystem. xfs_scrub likes to report progress information on
each phase of the scrub, which means that a strace for the entire
filesystem:
ioctl(3, FITRIM, {start=0x0, len=10995116277760, minlen=0}) = 0 <686.209839>
shows that scrub is uncommunicative for the entire duration. Reducing
the size of the FITRIM requests to a single AG at a time produces lower
times for each individual call, but even this isn't quite acceptable,
because the time between progress reports are still very high:
Strace for the first 4x 1TB AGs looks like (2):
ioctl(3, FITRIM, {start=0x0, len=1099511627776, minlen=0}) = 0 <68.352033>
ioctl(3, FITRIM, {start=0x10000000000, len=1099511627776, minlen=0}) = 0 <68.760323>
ioctl(3, FITRIM, {start=0x20000000000, len=1099511627776, minlen=0}) = 0 <67.235226>
ioctl(3, FITRIM, {start=0x30000000000, len=1099511627776, minlen=0}) = 0 <69.465744>
I then had the idea to limit the length parameter of each call to a
smallish amount (~11GB) so that we could report progress relatively
quickly, but much to my surprise, each FITRIM call still took ~68
seconds!
Unfortunately, the by-length fstrim implementation handles this poorly
because it walks the entire free space by length index (cntbt), which is
a very inefficient way to walk a subset of the blocks of an AG.
Therefore, create a second implementation that will walk the bnobt and
perform the trims in block number order. This implementation avoids the
worst problems of the original code, though it lacks the desirable
attribute of freeing the biggest chunks first.
On the other hand, this second implementation will be much easier to
constrain the system call latency, and makes it much easier to report
fstrim progress to anyone who's running xfs_scrub.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com
2024-04-16 05:55:06 +08:00
|
|
|
struct xfs_trim_cur {
|
|
|
|
xfs_agblock_t start;
|
|
|
|
xfs_extlen_t count;
|
|
|
|
xfs_agblock_t end;
|
|
|
|
xfs_extlen_t minlen;
|
|
|
|
bool by_bno;
|
|
|
|
};
|
2023-10-04 06:24:02 +08:00
|
|
|
|
2023-10-04 06:24:52 +08:00
|
|
|
static int
|
|
|
|
xfs_trim_gather_extents(
|
2023-02-13 06:14:54 +08:00
|
|
|
struct xfs_perag *pag,
|
xfs: fix performance problems when fstrimming a subset of a fragmented AG
On a 10TB filesystem where the free space in each AG is heavily
fragmented, I noticed some very high runtimes on a FITRIM call for the
entire filesystem. xfs_scrub likes to report progress information on
each phase of the scrub, which means that a strace for the entire
filesystem:
ioctl(3, FITRIM, {start=0x0, len=10995116277760, minlen=0}) = 0 <686.209839>
shows that scrub is uncommunicative for the entire duration. Reducing
the size of the FITRIM requests to a single AG at a time produces lower
times for each individual call, but even this isn't quite acceptable,
because the time between progress reports are still very high:
Strace for the first 4x 1TB AGs looks like (2):
ioctl(3, FITRIM, {start=0x0, len=1099511627776, minlen=0}) = 0 <68.352033>
ioctl(3, FITRIM, {start=0x10000000000, len=1099511627776, minlen=0}) = 0 <68.760323>
ioctl(3, FITRIM, {start=0x20000000000, len=1099511627776, minlen=0}) = 0 <67.235226>
ioctl(3, FITRIM, {start=0x30000000000, len=1099511627776, minlen=0}) = 0 <69.465744>
I then had the idea to limit the length parameter of each call to a
smallish amount (~11GB) so that we could report progress relatively
quickly, but much to my surprise, each FITRIM call still took ~68
seconds!
Unfortunately, the by-length fstrim implementation handles this poorly
because it walks the entire free space by length index (cntbt), which is
a very inefficient way to walk a subset of the blocks of an AG.
Therefore, create a second implementation that will walk the bnobt and
perform the trims in block number order. This implementation avoids the
worst problems of the original code, though it lacks the desirable
attribute of freeing the biggest chunks first.
On the other hand, this second implementation will be much easier to
constrain the system call latency, and makes it much easier to report
fstrim progress to anyone who's running xfs_scrub.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com
2024-04-16 05:55:06 +08:00
|
|
|
struct xfs_trim_cur *tcur,
|
2023-10-04 06:24:52 +08:00
|
|
|
struct xfs_busy_extents *extents,
|
2017-06-17 02:00:05 +08:00
|
|
|
uint64_t *blocks_trimmed)
|
2011-01-07 21:02:04 +08:00
|
|
|
{
|
2023-02-13 06:14:54 +08:00
|
|
|
struct xfs_mount *mp = pag->pag_mount;
|
2024-01-16 06:59:44 +08:00
|
|
|
struct xfs_trans *tp;
|
2011-01-07 21:02:04 +08:00
|
|
|
struct xfs_btree_cur *cur;
|
|
|
|
struct xfs_buf *agbp;
|
|
|
|
int error;
|
|
|
|
int i;
|
2023-10-04 06:24:52 +08:00
|
|
|
int batch = 100;
|
2011-01-07 21:02:04 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Force out the log. This means any transactions that might have freed
|
Force log to disk before reading the AGF during a fstrim
Forcing the log to disk after reading the agf is wrong, we might be
calling xfs_log_force with XFS_LOG_SYNC with a metadata lock held.
This can cause a deadlock when racing a fstrim with a filesystem
shutdown.
The deadlock has been identified due a miscalculation bug in device-mapper
dm-thin, which returns lack of space to its users earlier than the device itself
really runs out of space, changing the device-mapper volume into an error state.
The problem happened while filling the filesystem with a single file,
triggering the bug in device-mapper, consequently causing an IO error
and shutting down the filesystem.
If such file is removed, and fstrim executed before the XFS finishes the
shut down process, the fstrim process will end up holding the buffer
lock, and going to sleep on the cil wait queue.
At this point, the shut down process will try to wake up all the threads
waiting on the cil wait queue, but for this, it will try to hold the
same buffer log already held my the fstrim, locking up the filesystem.
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
2018-04-11 13:39:04 +08:00
|
|
|
* space before we take the AGF buffer lock are now on disk, and the
|
2011-01-07 21:02:04 +08:00
|
|
|
* volatile disk cache is flushed.
|
|
|
|
*/
|
|
|
|
xfs_log_force(mp, XFS_LOG_SYNC);
|
|
|
|
|
2024-01-16 06:59:44 +08:00
|
|
|
error = xfs_trans_alloc_empty(mp, &tp);
|
2020-01-24 09:01:20 +08:00
|
|
|
if (error)
|
2023-02-13 06:14:54 +08:00
|
|
|
return error;
|
Force log to disk before reading the AGF during a fstrim
Forcing the log to disk after reading the agf is wrong, we might be
calling xfs_log_force with XFS_LOG_SYNC with a metadata lock held.
This can cause a deadlock when racing a fstrim with a filesystem
shutdown.
The deadlock has been identified due a miscalculation bug in device-mapper
dm-thin, which returns lack of space to its users earlier than the device itself
really runs out of space, changing the device-mapper volume into an error state.
The problem happened while filling the filesystem with a single file,
triggering the bug in device-mapper, consequently causing an IO error
and shutting down the filesystem.
If such file is removed, and fstrim executed before the XFS finishes the
shut down process, the fstrim process will end up holding the buffer
lock, and going to sleep on the cil wait queue.
At this point, the shut down process will try to wake up all the threads
waiting on the cil wait queue, but for this, it will try to hold the
same buffer log already held my the fstrim, locking up the filesystem.
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
2018-04-11 13:39:04 +08:00
|
|
|
|
2024-01-16 06:59:44 +08:00
|
|
|
error = xfs_alloc_read_agf(pag, tp, 0, &agbp);
|
|
|
|
if (error)
|
|
|
|
goto out_trans_cancel;
|
|
|
|
|
xfs: fix performance problems when fstrimming a subset of a fragmented AG
On a 10TB filesystem where the free space in each AG is heavily
fragmented, I noticed some very high runtimes on a FITRIM call for the
entire filesystem. xfs_scrub likes to report progress information on
each phase of the scrub, which means that a strace for the entire
filesystem:
ioctl(3, FITRIM, {start=0x0, len=10995116277760, minlen=0}) = 0 <686.209839>
shows that scrub is uncommunicative for the entire duration. Reducing
the size of the FITRIM requests to a single AG at a time produces lower
times for each individual call, but even this isn't quite acceptable,
because the time between progress reports are still very high:
Strace for the first 4x 1TB AGs looks like (2):
ioctl(3, FITRIM, {start=0x0, len=1099511627776, minlen=0}) = 0 <68.352033>
ioctl(3, FITRIM, {start=0x10000000000, len=1099511627776, minlen=0}) = 0 <68.760323>
ioctl(3, FITRIM, {start=0x20000000000, len=1099511627776, minlen=0}) = 0 <67.235226>
ioctl(3, FITRIM, {start=0x30000000000, len=1099511627776, minlen=0}) = 0 <69.465744>
I then had the idea to limit the length parameter of each call to a
smallish amount (~11GB) so that we could report progress relatively
quickly, but much to my surprise, each FITRIM call still took ~68
seconds!
Unfortunately, the by-length fstrim implementation handles this poorly
because it walks the entire free space by length index (cntbt), which is
a very inefficient way to walk a subset of the blocks of an AG.
Therefore, create a second implementation that will walk the bnobt and
perform the trims in block number order. This implementation avoids the
worst problems of the original code, though it lacks the desirable
attribute of freeing the biggest chunks first.
On the other hand, this second implementation will be much easier to
constrain the system call latency, and makes it much easier to report
fstrim progress to anyone who's running xfs_scrub.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com
2024-04-16 05:55:06 +08:00
|
|
|
if (tcur->by_bno) {
|
|
|
|
/* sub-AG discard request always starts at tcur->start */
|
|
|
|
cur = xfs_bnobt_init_cursor(mp, tp, agbp, pag);
|
|
|
|
error = xfs_alloc_lookup_le(cur, tcur->start, 0, &i);
|
|
|
|
if (!error && !i)
|
|
|
|
error = xfs_alloc_lookup_ge(cur, tcur->start, 0, &i);
|
|
|
|
} else if (tcur->start == 0) {
|
|
|
|
/* first time through a by-len starts with max length */
|
|
|
|
cur = xfs_cntbt_init_cursor(mp, tp, agbp, pag);
|
|
|
|
error = xfs_alloc_lookup_ge(cur, 0, tcur->count, &i);
|
|
|
|
} else {
|
|
|
|
/* nth time through a by-len starts where we left off */
|
|
|
|
cur = xfs_cntbt_init_cursor(mp, tp, agbp, pag);
|
|
|
|
error = xfs_alloc_lookup_le(cur, tcur->start, tcur->count, &i);
|
|
|
|
}
|
2011-01-07 21:02:04 +08:00
|
|
|
if (error)
|
|
|
|
goto out_del_cursor;
|
2023-10-04 06:24:52 +08:00
|
|
|
if (i == 0) {
|
|
|
|
/* nothing of that length left in the AG, we are done */
|
xfs: fix performance problems when fstrimming a subset of a fragmented AG
On a 10TB filesystem where the free space in each AG is heavily
fragmented, I noticed some very high runtimes on a FITRIM call for the
entire filesystem. xfs_scrub likes to report progress information on
each phase of the scrub, which means that a strace for the entire
filesystem:
ioctl(3, FITRIM, {start=0x0, len=10995116277760, minlen=0}) = 0 <686.209839>
shows that scrub is uncommunicative for the entire duration. Reducing
the size of the FITRIM requests to a single AG at a time produces lower
times for each individual call, but even this isn't quite acceptable,
because the time between progress reports are still very high:
Strace for the first 4x 1TB AGs looks like (2):
ioctl(3, FITRIM, {start=0x0, len=1099511627776, minlen=0}) = 0 <68.352033>
ioctl(3, FITRIM, {start=0x10000000000, len=1099511627776, minlen=0}) = 0 <68.760323>
ioctl(3, FITRIM, {start=0x20000000000, len=1099511627776, minlen=0}) = 0 <67.235226>
ioctl(3, FITRIM, {start=0x30000000000, len=1099511627776, minlen=0}) = 0 <69.465744>
I then had the idea to limit the length parameter of each call to a
smallish amount (~11GB) so that we could report progress relatively
quickly, but much to my surprise, each FITRIM call still took ~68
seconds!
Unfortunately, the by-length fstrim implementation handles this poorly
because it walks the entire free space by length index (cntbt), which is
a very inefficient way to walk a subset of the blocks of an AG.
Therefore, create a second implementation that will walk the bnobt and
perform the trims in block number order. This implementation avoids the
worst problems of the original code, though it lacks the desirable
attribute of freeing the biggest chunks first.
On the other hand, this second implementation will be much easier to
constrain the system call latency, and makes it much easier to report
fstrim progress to anyone who's running xfs_scrub.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com
2024-04-16 05:55:06 +08:00
|
|
|
tcur->count = 0;
|
2023-10-04 06:24:52 +08:00
|
|
|
goto out_del_cursor;
|
|
|
|
}
|
2011-01-07 21:02:04 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Loop until we are done with all extents that are large
|
2023-10-04 06:24:52 +08:00
|
|
|
* enough to be worth discarding or we hit batch limits.
|
2011-01-07 21:02:04 +08:00
|
|
|
*/
|
|
|
|
while (i) {
|
2012-03-22 13:15:12 +08:00
|
|
|
xfs_agblock_t fbno;
|
|
|
|
xfs_extlen_t flen;
|
2011-01-07 21:02:04 +08:00
|
|
|
|
|
|
|
error = xfs_alloc_get_rec(cur, &fbno, &flen, &i);
|
|
|
|
if (error)
|
2023-02-13 06:14:54 +08:00
|
|
|
break;
|
xfs: kill the XFS_WANT_CORRUPT_* macros
The XFS_WANT_CORRUPT_* macros conceal subtle side effects such as the
creation of local variables and redirections of the code flow. This is
pretty ugly, so replace them with explicit XFS_IS_CORRUPT tests that
remove both of those ugly points. The change was performed with the
following coccinelle script:
@@
expression mp, test;
identifier label;
@@
- XFS_WANT_CORRUPTED_GOTO(mp, test, label);
+ if (XFS_IS_CORRUPT(mp, !test)) { error = -EFSCORRUPTED; goto label; }
@@
expression mp, test;
@@
- XFS_WANT_CORRUPTED_RETURN(mp, test);
+ if (XFS_IS_CORRUPT(mp, !test)) return -EFSCORRUPTED;
@@
expression mp, lval, rval;
@@
- XFS_IS_CORRUPT(mp, !(lval == rval))
+ XFS_IS_CORRUPT(mp, lval != rval)
@@
expression mp, e1, e2;
@@
- XFS_IS_CORRUPT(mp, !(e1 && e2))
+ XFS_IS_CORRUPT(mp, !e1 || !e2)
@@
expression e1, e2;
@@
- !(e1 == e2)
+ e1 != e2
@@
expression e1, e2, e3, e4, e5, e6;
@@
- !(e1 == e2 && e3 == e4) || e5 != e6
+ e1 != e2 || e3 != e4 || e5 != e6
@@
expression e1, e2, e3, e4, e5, e6;
@@
- !(e1 == e2 || (e3 <= e4 && e5 <= e6))
+ e1 != e2 && (e3 > e4 || e5 > e6)
@@
expression mp, e1, e2;
@@
- XFS_IS_CORRUPT(mp, !(e1 <= e2))
+ XFS_IS_CORRUPT(mp, e1 > e2)
@@
expression mp, e1, e2;
@@
- XFS_IS_CORRUPT(mp, !(e1 < e2))
+ XFS_IS_CORRUPT(mp, e1 >= e2)
@@
expression mp, e1;
@@
- XFS_IS_CORRUPT(mp, !!e1)
+ XFS_IS_CORRUPT(mp, e1)
@@
expression mp, e1, e2;
@@
- XFS_IS_CORRUPT(mp, !(e1 || e2))
+ XFS_IS_CORRUPT(mp, !e1 && !e2)
@@
expression mp, e1, e2, e3, e4;
@@
- XFS_IS_CORRUPT(mp, !(e1 == e2) && !(e3 == e4))
+ XFS_IS_CORRUPT(mp, e1 != e2 && e3 != e4)
@@
expression mp, e1, e2, e3, e4;
@@
- XFS_IS_CORRUPT(mp, !(e1 <= e2) || !(e3 >= e4))
+ XFS_IS_CORRUPT(mp, e1 > e2 || e3 < e4)
@@
expression mp, e1, e2, e3, e4;
@@
- XFS_IS_CORRUPT(mp, !(e1 == e2) && !(e3 <= e4))
+ XFS_IS_CORRUPT(mp, e1 != e2 && e3 > e4)
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2019-11-12 04:52:18 +08:00
|
|
|
if (XFS_IS_CORRUPT(mp, i != 1)) {
|
2024-02-23 04:32:55 +08:00
|
|
|
xfs_btree_mark_sick(cur);
|
xfs: kill the XFS_WANT_CORRUPT_* macros
The XFS_WANT_CORRUPT_* macros conceal subtle side effects such as the
creation of local variables and redirections of the code flow. This is
pretty ugly, so replace them with explicit XFS_IS_CORRUPT tests that
remove both of those ugly points. The change was performed with the
following coccinelle script:
@@
expression mp, test;
identifier label;
@@
- XFS_WANT_CORRUPTED_GOTO(mp, test, label);
+ if (XFS_IS_CORRUPT(mp, !test)) { error = -EFSCORRUPTED; goto label; }
@@
expression mp, test;
@@
- XFS_WANT_CORRUPTED_RETURN(mp, test);
+ if (XFS_IS_CORRUPT(mp, !test)) return -EFSCORRUPTED;
@@
expression mp, lval, rval;
@@
- XFS_IS_CORRUPT(mp, !(lval == rval))
+ XFS_IS_CORRUPT(mp, lval != rval)
@@
expression mp, e1, e2;
@@
- XFS_IS_CORRUPT(mp, !(e1 && e2))
+ XFS_IS_CORRUPT(mp, !e1 || !e2)
@@
expression e1, e2;
@@
- !(e1 == e2)
+ e1 != e2
@@
expression e1, e2, e3, e4, e5, e6;
@@
- !(e1 == e2 && e3 == e4) || e5 != e6
+ e1 != e2 || e3 != e4 || e5 != e6
@@
expression e1, e2, e3, e4, e5, e6;
@@
- !(e1 == e2 || (e3 <= e4 && e5 <= e6))
+ e1 != e2 && (e3 > e4 || e5 > e6)
@@
expression mp, e1, e2;
@@
- XFS_IS_CORRUPT(mp, !(e1 <= e2))
+ XFS_IS_CORRUPT(mp, e1 > e2)
@@
expression mp, e1, e2;
@@
- XFS_IS_CORRUPT(mp, !(e1 < e2))
+ XFS_IS_CORRUPT(mp, e1 >= e2)
@@
expression mp, e1;
@@
- XFS_IS_CORRUPT(mp, !!e1)
+ XFS_IS_CORRUPT(mp, e1)
@@
expression mp, e1, e2;
@@
- XFS_IS_CORRUPT(mp, !(e1 || e2))
+ XFS_IS_CORRUPT(mp, !e1 && !e2)
@@
expression mp, e1, e2, e3, e4;
@@
- XFS_IS_CORRUPT(mp, !(e1 == e2) && !(e3 == e4))
+ XFS_IS_CORRUPT(mp, e1 != e2 && e3 != e4)
@@
expression mp, e1, e2, e3, e4;
@@
- XFS_IS_CORRUPT(mp, !(e1 <= e2) || !(e3 >= e4))
+ XFS_IS_CORRUPT(mp, e1 > e2 || e3 < e4)
@@
expression mp, e1, e2, e3, e4;
@@
- XFS_IS_CORRUPT(mp, !(e1 == e2) && !(e3 <= e4))
+ XFS_IS_CORRUPT(mp, e1 != e2 && e3 > e4)
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2019-11-12 04:52:18 +08:00
|
|
|
error = -EFSCORRUPTED;
|
2023-02-13 06:14:54 +08:00
|
|
|
break;
|
xfs: kill the XFS_WANT_CORRUPT_* macros
The XFS_WANT_CORRUPT_* macros conceal subtle side effects such as the
creation of local variables and redirections of the code flow. This is
pretty ugly, so replace them with explicit XFS_IS_CORRUPT tests that
remove both of those ugly points. The change was performed with the
following coccinelle script:
@@
expression mp, test;
identifier label;
@@
- XFS_WANT_CORRUPTED_GOTO(mp, test, label);
+ if (XFS_IS_CORRUPT(mp, !test)) { error = -EFSCORRUPTED; goto label; }
@@
expression mp, test;
@@
- XFS_WANT_CORRUPTED_RETURN(mp, test);
+ if (XFS_IS_CORRUPT(mp, !test)) return -EFSCORRUPTED;
@@
expression mp, lval, rval;
@@
- XFS_IS_CORRUPT(mp, !(lval == rval))
+ XFS_IS_CORRUPT(mp, lval != rval)
@@
expression mp, e1, e2;
@@
- XFS_IS_CORRUPT(mp, !(e1 && e2))
+ XFS_IS_CORRUPT(mp, !e1 || !e2)
@@
expression e1, e2;
@@
- !(e1 == e2)
+ e1 != e2
@@
expression e1, e2, e3, e4, e5, e6;
@@
- !(e1 == e2 && e3 == e4) || e5 != e6
+ e1 != e2 || e3 != e4 || e5 != e6
@@
expression e1, e2, e3, e4, e5, e6;
@@
- !(e1 == e2 || (e3 <= e4 && e5 <= e6))
+ e1 != e2 && (e3 > e4 || e5 > e6)
@@
expression mp, e1, e2;
@@
- XFS_IS_CORRUPT(mp, !(e1 <= e2))
+ XFS_IS_CORRUPT(mp, e1 > e2)
@@
expression mp, e1, e2;
@@
- XFS_IS_CORRUPT(mp, !(e1 < e2))
+ XFS_IS_CORRUPT(mp, e1 >= e2)
@@
expression mp, e1;
@@
- XFS_IS_CORRUPT(mp, !!e1)
+ XFS_IS_CORRUPT(mp, e1)
@@
expression mp, e1, e2;
@@
- XFS_IS_CORRUPT(mp, !(e1 || e2))
+ XFS_IS_CORRUPT(mp, !e1 && !e2)
@@
expression mp, e1, e2, e3, e4;
@@
- XFS_IS_CORRUPT(mp, !(e1 == e2) && !(e3 == e4))
+ XFS_IS_CORRUPT(mp, e1 != e2 && e3 != e4)
@@
expression mp, e1, e2, e3, e4;
@@
- XFS_IS_CORRUPT(mp, !(e1 <= e2) || !(e3 >= e4))
+ XFS_IS_CORRUPT(mp, e1 > e2 || e3 < e4)
@@
expression mp, e1, e2, e3, e4;
@@
- XFS_IS_CORRUPT(mp, !(e1 == e2) && !(e3 <= e4))
+ XFS_IS_CORRUPT(mp, e1 != e2 && e3 > e4)
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2019-11-12 04:52:18 +08:00
|
|
|
}
|
2023-10-04 06:24:52 +08:00
|
|
|
|
|
|
|
if (--batch <= 0) {
|
|
|
|
/*
|
|
|
|
* Update the cursor to point at this extent so we
|
|
|
|
* restart the next batch from this extent.
|
|
|
|
*/
|
xfs: fix performance problems when fstrimming a subset of a fragmented AG
On a 10TB filesystem where the free space in each AG is heavily
fragmented, I noticed some very high runtimes on a FITRIM call for the
entire filesystem. xfs_scrub likes to report progress information on
each phase of the scrub, which means that a strace for the entire
filesystem:
ioctl(3, FITRIM, {start=0x0, len=10995116277760, minlen=0}) = 0 <686.209839>
shows that scrub is uncommunicative for the entire duration. Reducing
the size of the FITRIM requests to a single AG at a time produces lower
times for each individual call, but even this isn't quite acceptable,
because the time between progress reports are still very high:
Strace for the first 4x 1TB AGs looks like (2):
ioctl(3, FITRIM, {start=0x0, len=1099511627776, minlen=0}) = 0 <68.352033>
ioctl(3, FITRIM, {start=0x10000000000, len=1099511627776, minlen=0}) = 0 <68.760323>
ioctl(3, FITRIM, {start=0x20000000000, len=1099511627776, minlen=0}) = 0 <67.235226>
ioctl(3, FITRIM, {start=0x30000000000, len=1099511627776, minlen=0}) = 0 <69.465744>
I then had the idea to limit the length parameter of each call to a
smallish amount (~11GB) so that we could report progress relatively
quickly, but much to my surprise, each FITRIM call still took ~68
seconds!
Unfortunately, the by-length fstrim implementation handles this poorly
because it walks the entire free space by length index (cntbt), which is
a very inefficient way to walk a subset of the blocks of an AG.
Therefore, create a second implementation that will walk the bnobt and
perform the trims in block number order. This implementation avoids the
worst problems of the original code, though it lacks the desirable
attribute of freeing the biggest chunks first.
On the other hand, this second implementation will be much easier to
constrain the system call latency, and makes it much easier to report
fstrim progress to anyone who's running xfs_scrub.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com
2024-04-16 05:55:06 +08:00
|
|
|
tcur->start = fbno;
|
|
|
|
tcur->count = flen;
|
2023-02-13 06:14:54 +08:00
|
|
|
break;
|
2011-01-07 21:02:04 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the extent is entirely outside of the range we are
|
xfs: fix performance problems when fstrimming a subset of a fragmented AG
On a 10TB filesystem where the free space in each AG is heavily
fragmented, I noticed some very high runtimes on a FITRIM call for the
entire filesystem. xfs_scrub likes to report progress information on
each phase of the scrub, which means that a strace for the entire
filesystem:
ioctl(3, FITRIM, {start=0x0, len=10995116277760, minlen=0}) = 0 <686.209839>
shows that scrub is uncommunicative for the entire duration. Reducing
the size of the FITRIM requests to a single AG at a time produces lower
times for each individual call, but even this isn't quite acceptable,
because the time between progress reports are still very high:
Strace for the first 4x 1TB AGs looks like (2):
ioctl(3, FITRIM, {start=0x0, len=1099511627776, minlen=0}) = 0 <68.352033>
ioctl(3, FITRIM, {start=0x10000000000, len=1099511627776, minlen=0}) = 0 <68.760323>
ioctl(3, FITRIM, {start=0x20000000000, len=1099511627776, minlen=0}) = 0 <67.235226>
ioctl(3, FITRIM, {start=0x30000000000, len=1099511627776, minlen=0}) = 0 <69.465744>
I then had the idea to limit the length parameter of each call to a
smallish amount (~11GB) so that we could report progress relatively
quickly, but much to my surprise, each FITRIM call still took ~68
seconds!
Unfortunately, the by-length fstrim implementation handles this poorly
because it walks the entire free space by length index (cntbt), which is
a very inefficient way to walk a subset of the blocks of an AG.
Therefore, create a second implementation that will walk the bnobt and
perform the trims in block number order. This implementation avoids the
worst problems of the original code, though it lacks the desirable
attribute of freeing the biggest chunks first.
On the other hand, this second implementation will be much easier to
constrain the system call latency, and makes it much easier to report
fstrim progress to anyone who's running xfs_scrub.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com
2024-04-16 05:55:06 +08:00
|
|
|
* supposed to skip it. Do not bother to trim down partially
|
|
|
|
* overlapping ranges for now.
|
2011-01-07 21:02:04 +08:00
|
|
|
*/
|
xfs: fix performance problems when fstrimming a subset of a fragmented AG
On a 10TB filesystem where the free space in each AG is heavily
fragmented, I noticed some very high runtimes on a FITRIM call for the
entire filesystem. xfs_scrub likes to report progress information on
each phase of the scrub, which means that a strace for the entire
filesystem:
ioctl(3, FITRIM, {start=0x0, len=10995116277760, minlen=0}) = 0 <686.209839>
shows that scrub is uncommunicative for the entire duration. Reducing
the size of the FITRIM requests to a single AG at a time produces lower
times for each individual call, but even this isn't quite acceptable,
because the time between progress reports are still very high:
Strace for the first 4x 1TB AGs looks like (2):
ioctl(3, FITRIM, {start=0x0, len=1099511627776, minlen=0}) = 0 <68.352033>
ioctl(3, FITRIM, {start=0x10000000000, len=1099511627776, minlen=0}) = 0 <68.760323>
ioctl(3, FITRIM, {start=0x20000000000, len=1099511627776, minlen=0}) = 0 <67.235226>
ioctl(3, FITRIM, {start=0x30000000000, len=1099511627776, minlen=0}) = 0 <69.465744>
I then had the idea to limit the length parameter of each call to a
smallish amount (~11GB) so that we could report progress relatively
quickly, but much to my surprise, each FITRIM call still took ~68
seconds!
Unfortunately, the by-length fstrim implementation handles this poorly
because it walks the entire free space by length index (cntbt), which is
a very inefficient way to walk a subset of the blocks of an AG.
Therefore, create a second implementation that will walk the bnobt and
perform the trims in block number order. This implementation avoids the
worst problems of the original code, though it lacks the desirable
attribute of freeing the biggest chunks first.
On the other hand, this second implementation will be much easier to
constrain the system call latency, and makes it much easier to report
fstrim progress to anyone who's running xfs_scrub.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com
2024-04-16 05:55:06 +08:00
|
|
|
if (fbno + flen < tcur->start) {
|
|
|
|
trace_xfs_discard_exclude(mp, pag->pag_agno, fbno, flen);
|
|
|
|
goto next_extent;
|
|
|
|
}
|
|
|
|
if (fbno > tcur->end) {
|
2023-02-13 06:14:54 +08:00
|
|
|
trace_xfs_discard_exclude(mp, pag->pag_agno, fbno, flen);
|
xfs: fix performance problems when fstrimming a subset of a fragmented AG
On a 10TB filesystem where the free space in each AG is heavily
fragmented, I noticed some very high runtimes on a FITRIM call for the
entire filesystem. xfs_scrub likes to report progress information on
each phase of the scrub, which means that a strace for the entire
filesystem:
ioctl(3, FITRIM, {start=0x0, len=10995116277760, minlen=0}) = 0 <686.209839>
shows that scrub is uncommunicative for the entire duration. Reducing
the size of the FITRIM requests to a single AG at a time produces lower
times for each individual call, but even this isn't quite acceptable,
because the time between progress reports are still very high:
Strace for the first 4x 1TB AGs looks like (2):
ioctl(3, FITRIM, {start=0x0, len=1099511627776, minlen=0}) = 0 <68.352033>
ioctl(3, FITRIM, {start=0x10000000000, len=1099511627776, minlen=0}) = 0 <68.760323>
ioctl(3, FITRIM, {start=0x20000000000, len=1099511627776, minlen=0}) = 0 <67.235226>
ioctl(3, FITRIM, {start=0x30000000000, len=1099511627776, minlen=0}) = 0 <69.465744>
I then had the idea to limit the length parameter of each call to a
smallish amount (~11GB) so that we could report progress relatively
quickly, but much to my surprise, each FITRIM call still took ~68
seconds!
Unfortunately, the by-length fstrim implementation handles this poorly
because it walks the entire free space by length index (cntbt), which is
a very inefficient way to walk a subset of the blocks of an AG.
Therefore, create a second implementation that will walk the bnobt and
perform the trims in block number order. This implementation avoids the
worst problems of the original code, though it lacks the desirable
attribute of freeing the biggest chunks first.
On the other hand, this second implementation will be much easier to
constrain the system call latency, and makes it much easier to report
fstrim progress to anyone who's running xfs_scrub.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com
2024-04-16 05:55:06 +08:00
|
|
|
if (tcur->by_bno) {
|
|
|
|
tcur->count = 0;
|
|
|
|
break;
|
|
|
|
}
|
2011-01-07 21:02:04 +08:00
|
|
|
goto next_extent;
|
|
|
|
}
|
|
|
|
|
xfs: fix performance problems when fstrimming a subset of a fragmented AG
On a 10TB filesystem where the free space in each AG is heavily
fragmented, I noticed some very high runtimes on a FITRIM call for the
entire filesystem. xfs_scrub likes to report progress information on
each phase of the scrub, which means that a strace for the entire
filesystem:
ioctl(3, FITRIM, {start=0x0, len=10995116277760, minlen=0}) = 0 <686.209839>
shows that scrub is uncommunicative for the entire duration. Reducing
the size of the FITRIM requests to a single AG at a time produces lower
times for each individual call, but even this isn't quite acceptable,
because the time between progress reports are still very high:
Strace for the first 4x 1TB AGs looks like (2):
ioctl(3, FITRIM, {start=0x0, len=1099511627776, minlen=0}) = 0 <68.352033>
ioctl(3, FITRIM, {start=0x10000000000, len=1099511627776, minlen=0}) = 0 <68.760323>
ioctl(3, FITRIM, {start=0x20000000000, len=1099511627776, minlen=0}) = 0 <67.235226>
ioctl(3, FITRIM, {start=0x30000000000, len=1099511627776, minlen=0}) = 0 <69.465744>
I then had the idea to limit the length parameter of each call to a
smallish amount (~11GB) so that we could report progress relatively
quickly, but much to my surprise, each FITRIM call still took ~68
seconds!
Unfortunately, the by-length fstrim implementation handles this poorly
because it walks the entire free space by length index (cntbt), which is
a very inefficient way to walk a subset of the blocks of an AG.
Therefore, create a second implementation that will walk the bnobt and
perform the trims in block number order. This implementation avoids the
worst problems of the original code, though it lacks the desirable
attribute of freeing the biggest chunks first.
On the other hand, this second implementation will be much easier to
constrain the system call latency, and makes it much easier to report
fstrim progress to anyone who's running xfs_scrub.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com
2024-04-16 05:55:06 +08:00
|
|
|
/* Trim the extent returned to the range we want. */
|
|
|
|
if (fbno < tcur->start) {
|
|
|
|
flen -= tcur->start - fbno;
|
|
|
|
fbno = tcur->start;
|
|
|
|
}
|
|
|
|
if (fbno + flen > tcur->end + 1)
|
|
|
|
flen = tcur->end - fbno + 1;
|
|
|
|
|
|
|
|
/* Too small? Give up. */
|
|
|
|
if (flen < tcur->minlen) {
|
|
|
|
trace_xfs_discard_toosmall(mp, pag->pag_agno, fbno, flen);
|
|
|
|
if (tcur->by_bno)
|
|
|
|
goto next_extent;
|
|
|
|
tcur->count = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2011-01-07 21:02:04 +08:00
|
|
|
/*
|
|
|
|
* If any blocks in the range are still busy, skip the
|
|
|
|
* discard and try again the next time.
|
|
|
|
*/
|
2021-06-02 08:48:24 +08:00
|
|
|
if (xfs_extent_busy_search(mp, pag, fbno, flen)) {
|
2023-02-13 06:14:54 +08:00
|
|
|
trace_xfs_discard_busy(mp, pag->pag_agno, fbno, flen);
|
2011-01-07 21:02:04 +08:00
|
|
|
goto next_extent;
|
|
|
|
}
|
|
|
|
|
2023-10-04 06:24:52 +08:00
|
|
|
xfs_extent_busy_insert_discard(pag, fbno, flen,
|
|
|
|
&extents->extent_list);
|
2011-01-07 21:02:04 +08:00
|
|
|
*blocks_trimmed += flen;
|
|
|
|
next_extent:
|
xfs: fix performance problems when fstrimming a subset of a fragmented AG
On a 10TB filesystem where the free space in each AG is heavily
fragmented, I noticed some very high runtimes on a FITRIM call for the
entire filesystem. xfs_scrub likes to report progress information on
each phase of the scrub, which means that a strace for the entire
filesystem:
ioctl(3, FITRIM, {start=0x0, len=10995116277760, minlen=0}) = 0 <686.209839>
shows that scrub is uncommunicative for the entire duration. Reducing
the size of the FITRIM requests to a single AG at a time produces lower
times for each individual call, but even this isn't quite acceptable,
because the time between progress reports are still very high:
Strace for the first 4x 1TB AGs looks like (2):
ioctl(3, FITRIM, {start=0x0, len=1099511627776, minlen=0}) = 0 <68.352033>
ioctl(3, FITRIM, {start=0x10000000000, len=1099511627776, minlen=0}) = 0 <68.760323>
ioctl(3, FITRIM, {start=0x20000000000, len=1099511627776, minlen=0}) = 0 <67.235226>
ioctl(3, FITRIM, {start=0x30000000000, len=1099511627776, minlen=0}) = 0 <69.465744>
I then had the idea to limit the length parameter of each call to a
smallish amount (~11GB) so that we could report progress relatively
quickly, but much to my surprise, each FITRIM call still took ~68
seconds!
Unfortunately, the by-length fstrim implementation handles this poorly
because it walks the entire free space by length index (cntbt), which is
a very inefficient way to walk a subset of the blocks of an AG.
Therefore, create a second implementation that will walk the bnobt and
perform the trims in block number order. This implementation avoids the
worst problems of the original code, though it lacks the desirable
attribute of freeing the biggest chunks first.
On the other hand, this second implementation will be much easier to
constrain the system call latency, and makes it much easier to report
fstrim progress to anyone who's running xfs_scrub.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com
2024-04-16 05:55:06 +08:00
|
|
|
if (tcur->by_bno)
|
|
|
|
error = xfs_btree_increment(cur, 0, &i);
|
|
|
|
else
|
|
|
|
error = xfs_btree_decrement(cur, 0, &i);
|
2011-01-07 21:02:04 +08:00
|
|
|
if (error)
|
2023-02-13 06:14:54 +08:00
|
|
|
break;
|
2017-04-27 23:59:36 +08:00
|
|
|
|
2023-10-04 06:24:52 +08:00
|
|
|
/*
|
|
|
|
* If there's no more records in the tree, we are done. Set the
|
|
|
|
* cursor block count to 0 to indicate to the caller that there
|
|
|
|
* is no more extents to search.
|
|
|
|
*/
|
|
|
|
if (i == 0)
|
xfs: fix performance problems when fstrimming a subset of a fragmented AG
On a 10TB filesystem where the free space in each AG is heavily
fragmented, I noticed some very high runtimes on a FITRIM call for the
entire filesystem. xfs_scrub likes to report progress information on
each phase of the scrub, which means that a strace for the entire
filesystem:
ioctl(3, FITRIM, {start=0x0, len=10995116277760, minlen=0}) = 0 <686.209839>
shows that scrub is uncommunicative for the entire duration. Reducing
the size of the FITRIM requests to a single AG at a time produces lower
times for each individual call, but even this isn't quite acceptable,
because the time between progress reports are still very high:
Strace for the first 4x 1TB AGs looks like (2):
ioctl(3, FITRIM, {start=0x0, len=1099511627776, minlen=0}) = 0 <68.352033>
ioctl(3, FITRIM, {start=0x10000000000, len=1099511627776, minlen=0}) = 0 <68.760323>
ioctl(3, FITRIM, {start=0x20000000000, len=1099511627776, minlen=0}) = 0 <67.235226>
ioctl(3, FITRIM, {start=0x30000000000, len=1099511627776, minlen=0}) = 0 <69.465744>
I then had the idea to limit the length parameter of each call to a
smallish amount (~11GB) so that we could report progress relatively
quickly, but much to my surprise, each FITRIM call still took ~68
seconds!
Unfortunately, the by-length fstrim implementation handles this poorly
because it walks the entire free space by length index (cntbt), which is
a very inefficient way to walk a subset of the blocks of an AG.
Therefore, create a second implementation that will walk the bnobt and
perform the trims in block number order. This implementation avoids the
worst problems of the original code, though it lacks the desirable
attribute of freeing the biggest chunks first.
On the other hand, this second implementation will be much easier to
constrain the system call latency, and makes it much easier to report
fstrim progress to anyone who's running xfs_scrub.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com
2024-04-16 05:55:06 +08:00
|
|
|
tcur->count = 0;
|
2011-01-07 21:02:04 +08:00
|
|
|
}
|
|
|
|
|
2023-10-04 06:24:52 +08:00
|
|
|
/*
|
|
|
|
* If there was an error, release all the gathered busy extents because
|
|
|
|
* we aren't going to issue a discard on them any more.
|
|
|
|
*/
|
|
|
|
if (error)
|
|
|
|
xfs_extent_busy_clear(mp, &extents->extent_list, false);
|
2011-01-07 21:02:04 +08:00
|
|
|
out_del_cursor:
|
2018-07-20 03:26:31 +08:00
|
|
|
xfs_btree_del_cursor(cur, error);
|
2024-01-16 06:59:44 +08:00
|
|
|
out_trans_cancel:
|
|
|
|
xfs_trans_cancel(tp);
|
2011-01-07 21:02:04 +08:00
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2023-10-04 06:25:04 +08:00
|
|
|
static bool
|
|
|
|
xfs_trim_should_stop(void)
|
|
|
|
{
|
|
|
|
return fatal_signal_pending(current) || freezing(current);
|
|
|
|
}
|
|
|
|
|
2023-10-04 06:24:52 +08:00
|
|
|
/*
|
|
|
|
* Iterate the free list gathering extents and discarding them. We need a cursor
|
|
|
|
* for the repeated iteration of gather/discard loop, so use the longest extent
|
|
|
|
* we found in the last batch as the key to start the next.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
xfs_trim_extents(
|
|
|
|
struct xfs_perag *pag,
|
xfs: fix performance problems when fstrimming a subset of a fragmented AG
On a 10TB filesystem where the free space in each AG is heavily
fragmented, I noticed some very high runtimes on a FITRIM call for the
entire filesystem. xfs_scrub likes to report progress information on
each phase of the scrub, which means that a strace for the entire
filesystem:
ioctl(3, FITRIM, {start=0x0, len=10995116277760, minlen=0}) = 0 <686.209839>
shows that scrub is uncommunicative for the entire duration. Reducing
the size of the FITRIM requests to a single AG at a time produces lower
times for each individual call, but even this isn't quite acceptable,
because the time between progress reports are still very high:
Strace for the first 4x 1TB AGs looks like (2):
ioctl(3, FITRIM, {start=0x0, len=1099511627776, minlen=0}) = 0 <68.352033>
ioctl(3, FITRIM, {start=0x10000000000, len=1099511627776, minlen=0}) = 0 <68.760323>
ioctl(3, FITRIM, {start=0x20000000000, len=1099511627776, minlen=0}) = 0 <67.235226>
ioctl(3, FITRIM, {start=0x30000000000, len=1099511627776, minlen=0}) = 0 <69.465744>
I then had the idea to limit the length parameter of each call to a
smallish amount (~11GB) so that we could report progress relatively
quickly, but much to my surprise, each FITRIM call still took ~68
seconds!
Unfortunately, the by-length fstrim implementation handles this poorly
because it walks the entire free space by length index (cntbt), which is
a very inefficient way to walk a subset of the blocks of an AG.
Therefore, create a second implementation that will walk the bnobt and
perform the trims in block number order. This implementation avoids the
worst problems of the original code, though it lacks the desirable
attribute of freeing the biggest chunks first.
On the other hand, this second implementation will be much easier to
constrain the system call latency, and makes it much easier to report
fstrim progress to anyone who's running xfs_scrub.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com
2024-04-16 05:55:06 +08:00
|
|
|
xfs_agblock_t start,
|
|
|
|
xfs_agblock_t end,
|
|
|
|
xfs_extlen_t minlen,
|
2023-10-04 06:24:52 +08:00
|
|
|
uint64_t *blocks_trimmed)
|
|
|
|
{
|
xfs: fix performance problems when fstrimming a subset of a fragmented AG
On a 10TB filesystem where the free space in each AG is heavily
fragmented, I noticed some very high runtimes on a FITRIM call for the
entire filesystem. xfs_scrub likes to report progress information on
each phase of the scrub, which means that a strace for the entire
filesystem:
ioctl(3, FITRIM, {start=0x0, len=10995116277760, minlen=0}) = 0 <686.209839>
shows that scrub is uncommunicative for the entire duration. Reducing
the size of the FITRIM requests to a single AG at a time produces lower
times for each individual call, but even this isn't quite acceptable,
because the time between progress reports are still very high:
Strace for the first 4x 1TB AGs looks like (2):
ioctl(3, FITRIM, {start=0x0, len=1099511627776, minlen=0}) = 0 <68.352033>
ioctl(3, FITRIM, {start=0x10000000000, len=1099511627776, minlen=0}) = 0 <68.760323>
ioctl(3, FITRIM, {start=0x20000000000, len=1099511627776, minlen=0}) = 0 <67.235226>
ioctl(3, FITRIM, {start=0x30000000000, len=1099511627776, minlen=0}) = 0 <69.465744>
I then had the idea to limit the length parameter of each call to a
smallish amount (~11GB) so that we could report progress relatively
quickly, but much to my surprise, each FITRIM call still took ~68
seconds!
Unfortunately, the by-length fstrim implementation handles this poorly
because it walks the entire free space by length index (cntbt), which is
a very inefficient way to walk a subset of the blocks of an AG.
Therefore, create a second implementation that will walk the bnobt and
perform the trims in block number order. This implementation avoids the
worst problems of the original code, though it lacks the desirable
attribute of freeing the biggest chunks first.
On the other hand, this second implementation will be much easier to
constrain the system call latency, and makes it much easier to report
fstrim progress to anyone who's running xfs_scrub.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com
2024-04-16 05:55:06 +08:00
|
|
|
struct xfs_trim_cur tcur = {
|
|
|
|
.start = start,
|
|
|
|
.count = pag->pagf_longest,
|
|
|
|
.end = end,
|
|
|
|
.minlen = minlen,
|
2023-10-04 06:24:52 +08:00
|
|
|
};
|
|
|
|
int error = 0;
|
|
|
|
|
xfs: fix performance problems when fstrimming a subset of a fragmented AG
On a 10TB filesystem where the free space in each AG is heavily
fragmented, I noticed some very high runtimes on a FITRIM call for the
entire filesystem. xfs_scrub likes to report progress information on
each phase of the scrub, which means that a strace for the entire
filesystem:
ioctl(3, FITRIM, {start=0x0, len=10995116277760, minlen=0}) = 0 <686.209839>
shows that scrub is uncommunicative for the entire duration. Reducing
the size of the FITRIM requests to a single AG at a time produces lower
times for each individual call, but even this isn't quite acceptable,
because the time between progress reports are still very high:
Strace for the first 4x 1TB AGs looks like (2):
ioctl(3, FITRIM, {start=0x0, len=1099511627776, minlen=0}) = 0 <68.352033>
ioctl(3, FITRIM, {start=0x10000000000, len=1099511627776, minlen=0}) = 0 <68.760323>
ioctl(3, FITRIM, {start=0x20000000000, len=1099511627776, minlen=0}) = 0 <67.235226>
ioctl(3, FITRIM, {start=0x30000000000, len=1099511627776, minlen=0}) = 0 <69.465744>
I then had the idea to limit the length parameter of each call to a
smallish amount (~11GB) so that we could report progress relatively
quickly, but much to my surprise, each FITRIM call still took ~68
seconds!
Unfortunately, the by-length fstrim implementation handles this poorly
because it walks the entire free space by length index (cntbt), which is
a very inefficient way to walk a subset of the blocks of an AG.
Therefore, create a second implementation that will walk the bnobt and
perform the trims in block number order. This implementation avoids the
worst problems of the original code, though it lacks the desirable
attribute of freeing the biggest chunks first.
On the other hand, this second implementation will be much easier to
constrain the system call latency, and makes it much easier to report
fstrim progress to anyone who's running xfs_scrub.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com
2024-04-16 05:55:06 +08:00
|
|
|
if (start != 0 || end != pag->block_count)
|
|
|
|
tcur.by_bno = true;
|
|
|
|
|
2023-10-04 06:24:52 +08:00
|
|
|
do {
|
|
|
|
struct xfs_busy_extents *extents;
|
|
|
|
|
|
|
|
extents = kzalloc(sizeof(*extents), GFP_KERNEL);
|
|
|
|
if (!extents) {
|
|
|
|
error = -ENOMEM;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
extents->mount = pag->pag_mount;
|
|
|
|
extents->owner = extents;
|
|
|
|
INIT_LIST_HEAD(&extents->extent_list);
|
|
|
|
|
xfs: fix performance problems when fstrimming a subset of a fragmented AG
On a 10TB filesystem where the free space in each AG is heavily
fragmented, I noticed some very high runtimes on a FITRIM call for the
entire filesystem. xfs_scrub likes to report progress information on
each phase of the scrub, which means that a strace for the entire
filesystem:
ioctl(3, FITRIM, {start=0x0, len=10995116277760, minlen=0}) = 0 <686.209839>
shows that scrub is uncommunicative for the entire duration. Reducing
the size of the FITRIM requests to a single AG at a time produces lower
times for each individual call, but even this isn't quite acceptable,
because the time between progress reports are still very high:
Strace for the first 4x 1TB AGs looks like (2):
ioctl(3, FITRIM, {start=0x0, len=1099511627776, minlen=0}) = 0 <68.352033>
ioctl(3, FITRIM, {start=0x10000000000, len=1099511627776, minlen=0}) = 0 <68.760323>
ioctl(3, FITRIM, {start=0x20000000000, len=1099511627776, minlen=0}) = 0 <67.235226>
ioctl(3, FITRIM, {start=0x30000000000, len=1099511627776, minlen=0}) = 0 <69.465744>
I then had the idea to limit the length parameter of each call to a
smallish amount (~11GB) so that we could report progress relatively
quickly, but much to my surprise, each FITRIM call still took ~68
seconds!
Unfortunately, the by-length fstrim implementation handles this poorly
because it walks the entire free space by length index (cntbt), which is
a very inefficient way to walk a subset of the blocks of an AG.
Therefore, create a second implementation that will walk the bnobt and
perform the trims in block number order. This implementation avoids the
worst problems of the original code, though it lacks the desirable
attribute of freeing the biggest chunks first.
On the other hand, this second implementation will be much easier to
constrain the system call latency, and makes it much easier to report
fstrim progress to anyone who's running xfs_scrub.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com
2024-04-16 05:55:06 +08:00
|
|
|
error = xfs_trim_gather_extents(pag, &tcur, extents,
|
|
|
|
blocks_trimmed);
|
2023-10-04 06:24:52 +08:00
|
|
|
if (error) {
|
|
|
|
kfree(extents);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We hand the extent list to the discard function here so the
|
|
|
|
* discarded extents can be removed from the busy extent list.
|
|
|
|
* This allows the discards to run asynchronously with gathering
|
|
|
|
* the next round of extents to discard.
|
|
|
|
*
|
|
|
|
* However, we must ensure that we do not reference the extent
|
|
|
|
* list after this function call, as it may have been freed by
|
|
|
|
* the time control returns to us.
|
|
|
|
*/
|
|
|
|
error = xfs_discard_extents(pag->pag_mount, extents);
|
|
|
|
if (error)
|
|
|
|
break;
|
|
|
|
|
2023-10-04 06:25:04 +08:00
|
|
|
if (xfs_trim_should_stop())
|
2023-10-04 06:24:52 +08:00
|
|
|
break;
|
2023-10-04 06:25:04 +08:00
|
|
|
|
xfs: fix performance problems when fstrimming a subset of a fragmented AG
On a 10TB filesystem where the free space in each AG is heavily
fragmented, I noticed some very high runtimes on a FITRIM call for the
entire filesystem. xfs_scrub likes to report progress information on
each phase of the scrub, which means that a strace for the entire
filesystem:
ioctl(3, FITRIM, {start=0x0, len=10995116277760, minlen=0}) = 0 <686.209839>
shows that scrub is uncommunicative for the entire duration. Reducing
the size of the FITRIM requests to a single AG at a time produces lower
times for each individual call, but even this isn't quite acceptable,
because the time between progress reports are still very high:
Strace for the first 4x 1TB AGs looks like (2):
ioctl(3, FITRIM, {start=0x0, len=1099511627776, minlen=0}) = 0 <68.352033>
ioctl(3, FITRIM, {start=0x10000000000, len=1099511627776, minlen=0}) = 0 <68.760323>
ioctl(3, FITRIM, {start=0x20000000000, len=1099511627776, minlen=0}) = 0 <67.235226>
ioctl(3, FITRIM, {start=0x30000000000, len=1099511627776, minlen=0}) = 0 <69.465744>
I then had the idea to limit the length parameter of each call to a
smallish amount (~11GB) so that we could report progress relatively
quickly, but much to my surprise, each FITRIM call still took ~68
seconds!
Unfortunately, the by-length fstrim implementation handles this poorly
because it walks the entire free space by length index (cntbt), which is
a very inefficient way to walk a subset of the blocks of an AG.
Therefore, create a second implementation that will walk the bnobt and
perform the trims in block number order. This implementation avoids the
worst problems of the original code, though it lacks the desirable
attribute of freeing the biggest chunks first.
On the other hand, this second implementation will be much easier to
constrain the system call latency, and makes it much easier to report
fstrim progress to anyone who's running xfs_scrub.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com
2024-04-16 05:55:06 +08:00
|
|
|
} while (tcur.count != 0);
|
2023-10-04 06:24:52 +08:00
|
|
|
|
|
|
|
return error;
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2012-03-22 13:15:12 +08:00
|
|
|
/*
|
|
|
|
* trim a range of the filesystem.
|
|
|
|
*
|
|
|
|
* Note: the parameters passed from userspace are byte ranges into the
|
|
|
|
* filesystem which does not match to the format we use for filesystem block
|
|
|
|
* addressing. FSB addressing is sparse (AGNO|AGBNO), while the incoming format
|
|
|
|
* is a linear address range. Hence we need to use DADDR based conversions and
|
|
|
|
* comparisons for determining the correct offset and regions to trim.
|
|
|
|
*/
|
2011-01-07 21:02:04 +08:00
|
|
|
int
|
|
|
|
xfs_ioc_trim(
|
|
|
|
struct xfs_mount *mp,
|
|
|
|
struct fstrim_range __user *urange)
|
|
|
|
{
|
2023-02-13 06:14:54 +08:00
|
|
|
struct xfs_perag *pag;
|
2022-04-15 12:52:56 +08:00
|
|
|
unsigned int granularity =
|
|
|
|
bdev_discard_granularity(mp->m_ddev_targp->bt_bdev);
|
2011-01-07 21:02:04 +08:00
|
|
|
struct fstrim_range range;
|
xfs: fix performance problems when fstrimming a subset of a fragmented AG
On a 10TB filesystem where the free space in each AG is heavily
fragmented, I noticed some very high runtimes on a FITRIM call for the
entire filesystem. xfs_scrub likes to report progress information on
each phase of the scrub, which means that a strace for the entire
filesystem:
ioctl(3, FITRIM, {start=0x0, len=10995116277760, minlen=0}) = 0 <686.209839>
shows that scrub is uncommunicative for the entire duration. Reducing
the size of the FITRIM requests to a single AG at a time produces lower
times for each individual call, but even this isn't quite acceptable,
because the time between progress reports are still very high:
Strace for the first 4x 1TB AGs looks like (2):
ioctl(3, FITRIM, {start=0x0, len=1099511627776, minlen=0}) = 0 <68.352033>
ioctl(3, FITRIM, {start=0x10000000000, len=1099511627776, minlen=0}) = 0 <68.760323>
ioctl(3, FITRIM, {start=0x20000000000, len=1099511627776, minlen=0}) = 0 <67.235226>
ioctl(3, FITRIM, {start=0x30000000000, len=1099511627776, minlen=0}) = 0 <69.465744>
I then had the idea to limit the length parameter of each call to a
smallish amount (~11GB) so that we could report progress relatively
quickly, but much to my surprise, each FITRIM call still took ~68
seconds!
Unfortunately, the by-length fstrim implementation handles this poorly
because it walks the entire free space by length index (cntbt), which is
a very inefficient way to walk a subset of the blocks of an AG.
Therefore, create a second implementation that will walk the bnobt and
perform the trims in block number order. This implementation avoids the
worst problems of the original code, though it lacks the desirable
attribute of freeing the biggest chunks first.
On the other hand, this second implementation will be much easier to
constrain the system call latency, and makes it much easier to report
fstrim progress to anyone who's running xfs_scrub.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com
2024-04-16 05:55:06 +08:00
|
|
|
xfs_daddr_t start, end;
|
|
|
|
xfs_extlen_t minlen;
|
|
|
|
xfs_agnumber_t start_agno, end_agno;
|
|
|
|
xfs_agblock_t start_agbno, end_agbno;
|
2017-06-17 02:00:05 +08:00
|
|
|
uint64_t blocks_trimmed = 0;
|
2011-01-07 21:02:04 +08:00
|
|
|
int error, last_error = 0;
|
|
|
|
|
|
|
|
if (!capable(CAP_SYS_ADMIN))
|
2014-06-22 13:04:54 +08:00
|
|
|
return -EPERM;
|
2022-04-15 12:52:55 +08:00
|
|
|
if (!bdev_max_discard_sectors(mp->m_ddev_targp->bt_bdev))
|
2014-06-22 13:04:54 +08:00
|
|
|
return -EOPNOTSUPP;
|
2019-03-23 09:10:22 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We haven't recovered the log, so we cannot use our bnobt-guided
|
|
|
|
* storage zapping commands.
|
|
|
|
*/
|
2021-08-19 09:46:52 +08:00
|
|
|
if (xfs_has_norecovery(mp))
|
2019-03-23 09:10:22 +08:00
|
|
|
return -EROFS;
|
|
|
|
|
2011-01-07 21:02:04 +08:00
|
|
|
if (copy_from_user(&range, urange, sizeof(range)))
|
2014-06-22 13:04:54 +08:00
|
|
|
return -EFAULT;
|
2011-01-07 21:02:04 +08:00
|
|
|
|
2019-04-12 22:39:21 +08:00
|
|
|
range.minlen = max_t(u64, granularity, range.minlen);
|
xfs: fix performance problems when fstrimming a subset of a fragmented AG
On a 10TB filesystem where the free space in each AG is heavily
fragmented, I noticed some very high runtimes on a FITRIM call for the
entire filesystem. xfs_scrub likes to report progress information on
each phase of the scrub, which means that a strace for the entire
filesystem:
ioctl(3, FITRIM, {start=0x0, len=10995116277760, minlen=0}) = 0 <686.209839>
shows that scrub is uncommunicative for the entire duration. Reducing
the size of the FITRIM requests to a single AG at a time produces lower
times for each individual call, but even this isn't quite acceptable,
because the time between progress reports are still very high:
Strace for the first 4x 1TB AGs looks like (2):
ioctl(3, FITRIM, {start=0x0, len=1099511627776, minlen=0}) = 0 <68.352033>
ioctl(3, FITRIM, {start=0x10000000000, len=1099511627776, minlen=0}) = 0 <68.760323>
ioctl(3, FITRIM, {start=0x20000000000, len=1099511627776, minlen=0}) = 0 <67.235226>
ioctl(3, FITRIM, {start=0x30000000000, len=1099511627776, minlen=0}) = 0 <69.465744>
I then had the idea to limit the length parameter of each call to a
smallish amount (~11GB) so that we could report progress relatively
quickly, but much to my surprise, each FITRIM call still took ~68
seconds!
Unfortunately, the by-length fstrim implementation handles this poorly
because it walks the entire free space by length index (cntbt), which is
a very inefficient way to walk a subset of the blocks of an AG.
Therefore, create a second implementation that will walk the bnobt and
perform the trims in block number order. This implementation avoids the
worst problems of the original code, though it lacks the desirable
attribute of freeing the biggest chunks first.
On the other hand, this second implementation will be much easier to
constrain the system call latency, and makes it much easier to report
fstrim progress to anyone who's running xfs_scrub.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com
2024-04-16 05:55:06 +08:00
|
|
|
minlen = XFS_B_TO_FSB(mp, range.minlen);
|
|
|
|
|
2011-01-07 21:02:04 +08:00
|
|
|
/*
|
|
|
|
* Truncating down the len isn't actually quite correct, but using
|
2012-03-22 13:15:12 +08:00
|
|
|
* BBTOB would mean we trivially get overflows for values
|
2011-01-07 21:02:04 +08:00
|
|
|
* of ULLONG_MAX or slightly lower. And ULLONG_MAX is the default
|
|
|
|
* used by the fstrim application. In the end it really doesn't
|
|
|
|
* matter as trimming blocks is an advisory interface.
|
|
|
|
*/
|
2012-08-14 16:35:04 +08:00
|
|
|
if (range.start >= XFS_FSB_TO_B(mp, mp->m_sb.sb_dblocks) ||
|
2016-08-03 09:38:24 +08:00
|
|
|
range.minlen > XFS_FSB_TO_B(mp, mp->m_ag_max_usable) ||
|
2013-11-20 16:08:53 +08:00
|
|
|
range.len < mp->m_sb.sb_blocksize)
|
2014-06-22 13:04:54 +08:00
|
|
|
return -EINVAL;
|
2012-08-14 16:35:04 +08:00
|
|
|
|
2012-03-22 13:15:12 +08:00
|
|
|
start = BTOBB(range.start);
|
xfs: fix performance problems when fstrimming a subset of a fragmented AG
On a 10TB filesystem where the free space in each AG is heavily
fragmented, I noticed some very high runtimes on a FITRIM call for the
entire filesystem. xfs_scrub likes to report progress information on
each phase of the scrub, which means that a strace for the entire
filesystem:
ioctl(3, FITRIM, {start=0x0, len=10995116277760, minlen=0}) = 0 <686.209839>
shows that scrub is uncommunicative for the entire duration. Reducing
the size of the FITRIM requests to a single AG at a time produces lower
times for each individual call, but even this isn't quite acceptable,
because the time between progress reports are still very high:
Strace for the first 4x 1TB AGs looks like (2):
ioctl(3, FITRIM, {start=0x0, len=1099511627776, minlen=0}) = 0 <68.352033>
ioctl(3, FITRIM, {start=0x10000000000, len=1099511627776, minlen=0}) = 0 <68.760323>
ioctl(3, FITRIM, {start=0x20000000000, len=1099511627776, minlen=0}) = 0 <67.235226>
ioctl(3, FITRIM, {start=0x30000000000, len=1099511627776, minlen=0}) = 0 <69.465744>
I then had the idea to limit the length parameter of each call to a
smallish amount (~11GB) so that we could report progress relatively
quickly, but much to my surprise, each FITRIM call still took ~68
seconds!
Unfortunately, the by-length fstrim implementation handles this poorly
because it walks the entire free space by length index (cntbt), which is
a very inefficient way to walk a subset of the blocks of an AG.
Therefore, create a second implementation that will walk the bnobt and
perform the trims in block number order. This implementation avoids the
worst problems of the original code, though it lacks the desirable
attribute of freeing the biggest chunks first.
On the other hand, this second implementation will be much easier to
constrain the system call latency, and makes it much easier to report
fstrim progress to anyone who's running xfs_scrub.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com
2024-04-16 05:55:06 +08:00
|
|
|
end = min_t(xfs_daddr_t, start + BTOBBT(range.len),
|
|
|
|
XFS_FSB_TO_BB(mp, mp->m_sb.sb_dblocks)) - 1;
|
|
|
|
|
|
|
|
start_agno = xfs_daddr_to_agno(mp, start);
|
|
|
|
start_agbno = xfs_daddr_to_agbno(mp, start);
|
|
|
|
end_agno = xfs_daddr_to_agno(mp, end);
|
|
|
|
end_agbno = xfs_daddr_to_agbno(mp, end);
|
2011-01-07 21:02:04 +08:00
|
|
|
|
xfs: fix performance problems when fstrimming a subset of a fragmented AG
On a 10TB filesystem where the free space in each AG is heavily
fragmented, I noticed some very high runtimes on a FITRIM call for the
entire filesystem. xfs_scrub likes to report progress information on
each phase of the scrub, which means that a strace for the entire
filesystem:
ioctl(3, FITRIM, {start=0x0, len=10995116277760, minlen=0}) = 0 <686.209839>
shows that scrub is uncommunicative for the entire duration. Reducing
the size of the FITRIM requests to a single AG at a time produces lower
times for each individual call, but even this isn't quite acceptable,
because the time between progress reports are still very high:
Strace for the first 4x 1TB AGs looks like (2):
ioctl(3, FITRIM, {start=0x0, len=1099511627776, minlen=0}) = 0 <68.352033>
ioctl(3, FITRIM, {start=0x10000000000, len=1099511627776, minlen=0}) = 0 <68.760323>
ioctl(3, FITRIM, {start=0x20000000000, len=1099511627776, minlen=0}) = 0 <67.235226>
ioctl(3, FITRIM, {start=0x30000000000, len=1099511627776, minlen=0}) = 0 <69.465744>
I then had the idea to limit the length parameter of each call to a
smallish amount (~11GB) so that we could report progress relatively
quickly, but much to my surprise, each FITRIM call still took ~68
seconds!
Unfortunately, the by-length fstrim implementation handles this poorly
because it walks the entire free space by length index (cntbt), which is
a very inefficient way to walk a subset of the blocks of an AG.
Therefore, create a second implementation that will walk the bnobt and
perform the trims in block number order. This implementation avoids the
worst problems of the original code, though it lacks the desirable
attribute of freeing the biggest chunks first.
On the other hand, this second implementation will be much easier to
constrain the system call latency, and makes it much easier to report
fstrim progress to anyone who's running xfs_scrub.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com
2024-04-16 05:55:06 +08:00
|
|
|
for_each_perag_range(mp, start_agno, end_agno, pag) {
|
|
|
|
xfs_agblock_t agend = pag->block_count;
|
2011-01-07 21:02:04 +08:00
|
|
|
|
xfs: fix performance problems when fstrimming a subset of a fragmented AG
On a 10TB filesystem where the free space in each AG is heavily
fragmented, I noticed some very high runtimes on a FITRIM call for the
entire filesystem. xfs_scrub likes to report progress information on
each phase of the scrub, which means that a strace for the entire
filesystem:
ioctl(3, FITRIM, {start=0x0, len=10995116277760, minlen=0}) = 0 <686.209839>
shows that scrub is uncommunicative for the entire duration. Reducing
the size of the FITRIM requests to a single AG at a time produces lower
times for each individual call, but even this isn't quite acceptable,
because the time between progress reports are still very high:
Strace for the first 4x 1TB AGs looks like (2):
ioctl(3, FITRIM, {start=0x0, len=1099511627776, minlen=0}) = 0 <68.352033>
ioctl(3, FITRIM, {start=0x10000000000, len=1099511627776, minlen=0}) = 0 <68.760323>
ioctl(3, FITRIM, {start=0x20000000000, len=1099511627776, minlen=0}) = 0 <67.235226>
ioctl(3, FITRIM, {start=0x30000000000, len=1099511627776, minlen=0}) = 0 <69.465744>
I then had the idea to limit the length parameter of each call to a
smallish amount (~11GB) so that we could report progress relatively
quickly, but much to my surprise, each FITRIM call still took ~68
seconds!
Unfortunately, the by-length fstrim implementation handles this poorly
because it walks the entire free space by length index (cntbt), which is
a very inefficient way to walk a subset of the blocks of an AG.
Therefore, create a second implementation that will walk the bnobt and
perform the trims in block number order. This implementation avoids the
worst problems of the original code, though it lacks the desirable
attribute of freeing the biggest chunks first.
On the other hand, this second implementation will be much easier to
constrain the system call latency, and makes it much easier to report
fstrim progress to anyone who's running xfs_scrub.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com
2024-04-16 05:55:06 +08:00
|
|
|
if (start_agno == end_agno)
|
|
|
|
agend = end_agbno;
|
|
|
|
error = xfs_trim_extents(pag, start_agbno, agend, minlen,
|
|
|
|
&blocks_trimmed);
|
2023-10-04 06:25:04 +08:00
|
|
|
if (error)
|
2011-01-07 21:02:04 +08:00
|
|
|
last_error = error;
|
2023-10-04 06:25:04 +08:00
|
|
|
|
|
|
|
if (xfs_trim_should_stop()) {
|
|
|
|
xfs_perag_rele(pag);
|
|
|
|
break;
|
2017-04-27 23:59:36 +08:00
|
|
|
}
|
xfs: fix performance problems when fstrimming a subset of a fragmented AG
On a 10TB filesystem where the free space in each AG is heavily
fragmented, I noticed some very high runtimes on a FITRIM call for the
entire filesystem. xfs_scrub likes to report progress information on
each phase of the scrub, which means that a strace for the entire
filesystem:
ioctl(3, FITRIM, {start=0x0, len=10995116277760, minlen=0}) = 0 <686.209839>
shows that scrub is uncommunicative for the entire duration. Reducing
the size of the FITRIM requests to a single AG at a time produces lower
times for each individual call, but even this isn't quite acceptable,
because the time between progress reports are still very high:
Strace for the first 4x 1TB AGs looks like (2):
ioctl(3, FITRIM, {start=0x0, len=1099511627776, minlen=0}) = 0 <68.352033>
ioctl(3, FITRIM, {start=0x10000000000, len=1099511627776, minlen=0}) = 0 <68.760323>
ioctl(3, FITRIM, {start=0x20000000000, len=1099511627776, minlen=0}) = 0 <67.235226>
ioctl(3, FITRIM, {start=0x30000000000, len=1099511627776, minlen=0}) = 0 <69.465744>
I then had the idea to limit the length parameter of each call to a
smallish amount (~11GB) so that we could report progress relatively
quickly, but much to my surprise, each FITRIM call still took ~68
seconds!
Unfortunately, the by-length fstrim implementation handles this poorly
because it walks the entire free space by length index (cntbt), which is
a very inefficient way to walk a subset of the blocks of an AG.
Therefore, create a second implementation that will walk the bnobt and
perform the trims in block number order. This implementation avoids the
worst problems of the original code, though it lacks the desirable
attribute of freeing the biggest chunks first.
On the other hand, this second implementation will be much easier to
constrain the system call latency, and makes it much easier to report
fstrim progress to anyone who's running xfs_scrub.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com
2024-04-16 05:55:06 +08:00
|
|
|
start_agbno = 0;
|
2011-01-07 21:02:04 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (last_error)
|
|
|
|
return last_error;
|
|
|
|
|
|
|
|
range.len = XFS_FSB_TO_B(mp, blocks_trimmed);
|
|
|
|
if (copy_to_user(urange, &range, sizeof(range)))
|
2014-06-22 13:04:54 +08:00
|
|
|
return -EFAULT;
|
2011-01-07 21:02:04 +08:00
|
|
|
return 0;
|
|
|
|
}
|