From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: xfs <linux-xfs@vger.kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Gao Xiang <hsiangkao@linux.alibaba.com>
Subject: [PATCH 0/3] xfs: some end COW remapping optimization
Date: Wed, 9 Feb 2022 15:36:52 +0800 [thread overview]
Message-ID: <20220209073655.22162-1-hsiangkao@linux.alibaba.com> (raw)
Hi folks,
Currently, xfs_reflink_end_cow_extent() will unconditionally unmap an
extent from DATA fork and then remap an extent from COW fork. It seems
somewhat ineffective since for many cases we could update real bmbt
records directly by sightly enhancing old
xfs_bmap_add_extent_unwritten_real() implementation, thus reduce some
measurable extra metadata overhead.
It's important to us since, actually, we're planing to use a modified
alway-cow like atomic write approach internally for database
applications, therefore it'd be nice to do some optimization over
simple end COW approach. Also I think it's still generic and can
benefit other reflink use cases as well.
I did some tests with ramdisk in order to measure metadata overhead:
echo 1 > /sys/fs/xfs/debug/always_cow
mkfs.xfs -f -mreflink=1 /dev/ram0
mount /dev/ram0 testdir
fio -filename=testdir/1 -size=1G -ioengine=psync -bs=4k -rw=randwrite -overwrite=1 -direct=1 -end_fsync=1 -name=job1
Test results as below:
Vanilla:
(1) iops : min= 7986, max=16434, avg=12505.76, stdev=2400.05, samples=41
(2) iops : min= 7636, max=16376, avg=12474.19, stdev=2258.18, samples=42
(3) iops : min= 8346, max=16439, avg=12227.95, stdev=2432.12, samples=42
(4) iops : min= 8580, max=16496, avg=12779.41, stdev=2297.42, samples=41
(5) iops : min= 8286, max=16556, avg=12500.76, stdev=2123.90, samples=41
Patched:
(1) iops : min= 7086, max=17132, avg=12931.20, stdev=2729.10, samples=40
(2) iops : min= 7704, max=17508, avg=13204.62, stdev=2507.70, samples=39
(3) iops : min= 8736, max=17634, avg=13253.08, stdev=2545.18, samples=39
(4) iops : min= 7188, max=17550, avg=12928.40, stdev=2633.64, samples=40
(5) iops : min= 8268, max=17446, avg=12837.55, stdev=2717.98, samples=40
It's still immature so far yet xfstests seems survived.
Comments are much welcomed and thanks for your time!
Thanks,
Gao Xiang
Gao Xiang (3):
xfs: get rid of LEFT, RIGHT, PREV in
xfs_bmap_add_extent_unwritten_real()
xfs: introduce xfs_bmap_update_extent_real()
xfs: introduce xfs_bremapi_from_cowfork()
fs/xfs/libxfs/xfs_bmap.c | 378 +++++++++++++++++++++++++--------------
fs/xfs/libxfs/xfs_bmap.h | 7 +-
fs/xfs/xfs_reflink.c | 24 +--
3 files changed, 253 insertions(+), 156 deletions(-)
--
2.24.4
next reply other threads:[~2022-02-09 7:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-09 7:36 Gao Xiang [this message]
2022-02-09 7:36 ` [PATCH 1/3] xfs: get rid of LEFT, RIGHT, PREV in xfs_bmap_add_extent_unwritten_real() Gao Xiang
2022-02-09 7:36 ` [PATCH 2/3] xfs: introduce xfs_bmap_update_extent_real() Gao Xiang
2022-02-09 7:36 ` [PATCH 3/3] xfs: introduce xfs_bremapi_from_cowfork() Gao Xiang
2022-02-16 1:24 ` Darrick J. Wong
2022-02-16 2:03 ` Gao Xiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220209073655.22162-1-hsiangkao@linux.alibaba.com \
--to=hsiangkao@linux.alibaba.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox