From: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
To: Pankaj Raghav <p.raghav@samsung.com>,
"fstests@vger.kernel.org" <fstests@vger.kernel.org>
Cc: "damien.lemoal@opensource.wdc.com"
<damien.lemoal@opensource.wdc.com>,
"pankydev8@gmail.com" <pankydev8@gmail.com>,
Naohiro Aota <Naohiro.Aota@wdc.com>,
"gost.dev@samsung.com" <gost.dev@samsung.com>,
"mcgrof@kernel.org" <mcgrof@kernel.org>,
"dsterba@suse.cz" <dsterba@suse.cz>,
zorro Lang <zlang@redhat.com>
Subject: Re: [RFC 0/1] adapting btrfs/237 to work with the new reclaim algorithm
Date: Mon, 5 Dec 2022 07:56:01 +0000 [thread overview]
Message-ID: <76cec363-4652-0cdf-db44-3ce0e56dbb42@wdc.com> (raw)
In-Reply-To: <20220819115337.35681-1-p.raghav@samsung.com>
On 19.08.22 13:53, Pankaj Raghav wrote:
> Hi ,
> Since 3687fcb0752a ("btrfs: zoned: make auto-reclaim less aggressive")
> commit, reclaim algorithm has been changed to trigger auto-reclaim once
> the fs used size is more than a certain threshold. This change breaks
> 237 test.
>
> I tried to adapt the test by doing the following:
> - Write a small file first
> - Write a big file that increases the disk usage to be more than the
> reclaim threshold
> - Delete the big file to trigger threshold
> - Ensure the small file is relocated and the space used by the big file
> is reclaimed.
>
> My test case works properly for small ZNS drives but not for bigger
> sized drives in QEMU. When I use a drive with a size of 100G, not all
> zones that were used by the big file are correctly reclaimed.
> Either I am not setting up the test correctly or there is something
> wrong on how reclaim works for zoned devices.
>
> I created a simple script to reproduce the scenario instead of running
> the test. Please adapt the $DEV and $big_file_size based on the drive
> size. As I am setting the bg_reclaim_threshold to be 51, $big_file_size
> should be at least 51% of the drive size.
>
> ```
> DEV=nvme0n3
> DEV_PATH=/dev/$DEV
> big_file_size=2500M
>
> echo "mq-deadline" > /sys/block/$DEV/queue/scheduler
> umount /mnt/scratch
> blkzone reset $DEV_PATH
> mkfs.btrfs -f -d single -m single $DEV_PATH > /dev/null; mount -t btrfs $DEV_PATH \
> /mnt/scratch
> uuid=$(btrfs fi show $DEV_PATH | grep 'uuid' | awk '{print $NF}')
>
> echo "51" > /sys/fs/btrfs/$uuid/bg_reclaim_threshold
>
> fio --filename=/mnt/scratch/test2 --size=1M --rw=write --bs=4k \
> --name=btrfs_zoned > /dev/null
> btrfs fi sync /mnt/scratch
>
> echo "Open zones before big file trasfer:"
> blkzone report $DEV_PATH | grep -v -e em -e nw | wc -l
>
> fio --filename=/mnt/scratch/test1 --size=$big_file_size --rw=write --bs=4k \
> --ioengine=io_uring --name=btrfs_zoned > /dev/null
> btrfs fi sync /mnt/scratch
>
> echo "Open zones before removing the file:"
> blkzone report $DEV_PATH | grep -v -e em -e nw | wc -l
> rm /mnt/scratch/test1
> btrfs fi sync /mnt/scratch
>
> echo "Going to sleep. Removed the file"
> sleep 30
>
> echo "Open zones after reclaim:"
> blkzone report $DEV_PATH | grep -v -e em -e nw | wc -l
> ```
>
> I am getting the following output in QEMU:
>
> - 5GB ZNS drive with 128MB zone size (and cap) and it is working as
> expected:
>
> ```
> Open zones before big file trasfer:
> 4
> Open zones before removing the file:
> 23
> Going to sleep. Removed the file
> Open zones after reclaim:
> 4
> ```
>
> - 100GB ZNS drive with 128MB zone size (and cap) and it is **not
> working** as expected:
>
> ```
> Open zones before big file trasfer:
> 4
> Open zones before removing the file:
> 455
> Going to sleep. Removed the file
> Open zones after reclaim:
> 411
> ```
>
> Only partial reclaim is happening for bigger sized drives. The issue
> with that is, if I do another FIO transfer, the drive spits out ENOSPC
> before its actual capacity is reached as most of the zones have not been
> reclaimed back and are basically in an unusable state.
>
> Is there a limit on how many bgs can be reclaimed?
>
> Let me know if I am doing something wrong in the test or if it is an
> actual issue.
>
> Pankaj Raghav (1):
> btrfs/237: adapt the test to work with the new reclaim algorithm
>
> tests/btrfs/237 | 80 +++++++++++++++++++++++++++++++++++--------------
> 1 file changed, 57 insertions(+), 23 deletions(-)
>
Btw, what ever happend to this patch?
prev parent reply other threads:[~2022-12-05 7:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20220819115338eucas1p11b916296213572e97a03241ebdc399d0@eucas1p1.samsung.com>
2022-08-19 11:53 ` [RFC 0/1] adapting btrfs/237 to work with the new reclaim algorithm Pankaj Raghav
2022-08-19 11:53 ` [RFC 1/1] btrfs/237: adapt the test " Pankaj Raghav
2022-08-22 9:40 ` Johannes Thumshirn
2022-08-22 10:49 ` Pankaj Raghav
2022-08-22 12:22 ` Johannes Thumshirn
2022-08-22 14:29 ` [RFC 0/1] adapting btrfs/237 " Johannes Thumshirn
2022-08-23 11:46 ` Pankaj Raghav
2022-12-05 14:53 ` Pankaj Raghav
2022-12-05 16:04 ` Johannes Thumshirn
2022-12-07 16:01 ` Pankaj Raghav
2022-12-13 13:35 ` Pankaj Raghav
2022-12-05 7:56 ` Johannes Thumshirn [this message]
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=76cec363-4652-0cdf-db44-3ce0e56dbb42@wdc.com \
--to=johannes.thumshirn@wdc.com \
--cc=Naohiro.Aota@wdc.com \
--cc=damien.lemoal@opensource.wdc.com \
--cc=dsterba@suse.cz \
--cc=fstests@vger.kernel.org \
--cc=gost.dev@samsung.com \
--cc=mcgrof@kernel.org \
--cc=p.raghav@samsung.com \
--cc=pankydev8@gmail.com \
--cc=zlang@redhat.com \
/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