diff mbox series

[1/2] common: introduce zone_capacity() to return a zone capacity

Message ID 97ede9bba67f0848fc0b706d757170d7dfacb7fd.1663825728.git.naohiro.aota@wdc.com (mailing list archive)
State New, archived
Headers show
Series btrfs: test active zone tracking | expand

Commit Message

Naohiro Aota Sept. 22, 2022, 5:54 a.m. UTC
Introduce _zone_capacity() to return a zone capacity of the given address
in the given device (optional). Rewrite btrfs/237 with it.

Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
---
 common/zbd      | 17 +++++++++++++++++
 tests/btrfs/237 |  8 ++------
 2 files changed, 19 insertions(+), 6 deletions(-)
 create mode 100644 common/zbd

Comments

Zorro Lang Sept. 22, 2022, 3:41 p.m. UTC | #1
On Thu, Sep 22, 2022 at 02:54:58PM +0900, Naohiro Aota wrote:
> Introduce _zone_capacity() to return a zone capacity of the given address
> in the given device (optional). Rewrite btrfs/237 with it.
> 
> Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
> ---
>  common/zbd      | 17 +++++++++++++++++
>  tests/btrfs/237 |  8 ++------
>  2 files changed, 19 insertions(+), 6 deletions(-)
>  create mode 100644 common/zbd
> 
> diff --git a/common/zbd b/common/zbd
> new file mode 100644
> index 000000000000..329bb7be6b7b
> --- /dev/null
> +++ b/common/zbd

I don't like this abbreviation :-P If others don't open this file and read the
comment in it, they nearly no chance to guess what's this file for.

> @@ -0,0 +1,17 @@
> +#
> +# Common zoned block device specific functions
> +#
> +
> +. common/filter
> +
> +_zone_capacity() {
> +    local phy=$1
> +    local dev=$2
> +
> +    [ -z "$dev" ] && dev=$SCRATCH_DEV
> +
> +    size=$($BLKZONE_PROG report -o $phy -l 1 $dev |\
> +	       _filter_blkzone_report |\
> +	       grep -Po "cap 0x[[:xdigit:]]+" | cut -d ' ' -f 2)
> +    echo $((size << 9))
> +}

Do you have more zone related helpers are going to provide? If only this
single one helper, I think it's not worth adding a new common file. You
can put it into common/rc simply, as there're already several *zone*
related helpers in it.

We can pick up these *zone* related function into a separate include file in
one day we feel it's time (too many related helpers, and better to be maintained
individually).

Thanks,
Zorro

> diff --git a/tests/btrfs/237 b/tests/btrfs/237
> index bc6522e2200a..101094b5ce70 100755
> --- a/tests/btrfs/237
> +++ b/tests/btrfs/237
> @@ -13,7 +13,7 @@
>  _begin_fstest auto quick zone balance
>  
>  # Import common functions.
> -. ./common/filter
> +. ./common/zbd
>  
>  # real QA test starts here
>  
> @@ -56,11 +56,7 @@ fi
>  
>  start_data_bg_phy=$(get_data_bg_physical)
>  start_data_bg_phy=$((start_data_bg_phy >> 9))
> -
> -size=$($BLKZONE_PROG report -o $start_data_bg_phy -l 1 $SCRATCH_DEV |\
> -	_filter_blkzone_report |\
> -	grep -Po "cap 0x[[:xdigit:]]+" | cut -d ' ' -f 2)
> -size=$((size << 9))
> +size=$(_zone_capacity $start_data_bg_phy)
>  
>  reclaim_threshold=75
>  echo $reclaim_threshold > /sys/fs/btrfs/"$uuid"/bg_reclaim_threshold
> -- 
> 2.37.3
>
Johannes Thumshirn Sept. 23, 2022, 8:02 a.m. UTC | #2
On 22.09.22 17:42, Zorro Lang wrote:
>> --- /dev/null
>> +++ b/common/zbd
> I don't like this abbreviation :-P If others don't open this file and read the
> comment in it, they nearly no chance to guess what's this file for.
> 

zbd is a well known abbreviation for zoned block devices. I think most
people in storage and filesystems know it.
Zorro Lang Sept. 23, 2022, 11:51 a.m. UTC | #3
On Fri, Sep 23, 2022 at 08:02:10AM +0000, Johannes Thumshirn wrote:
> On 22.09.22 17:42, Zorro Lang wrote:
> >> --- /dev/null
> >> +++ b/common/zbd
> > I don't like this abbreviation :-P If others don't open this file and read the
> > comment in it, they nearly no chance to guess what's this file for.
> > 
> 
> zbd is a well known abbreviation for zoned block devices. I think most
> people in storage and filesystems know it.

OK, but we haven't been that "a single character is worth a thousand
pieces of gold", so we can use a longer name, likes common/zone,
common/zoned, common/zoned_block, common/zoned_device or something likes
that. Anyway, that's just my personal opinion, if most of people prefer
using "common/zbd", I'm fine to have that :) 

But I hope you can move all zoned block device related helpers to the new
common file if you'd like to bring in this file, likes what Darrick did in:

commit 67afd5c742464607994316acb2c6e8303b8af4c5
Author: Darrick J. Wong <djwong@kernel.org>
Date:   Tue Aug 9 14:00:46 2022 -0700

    common/rc: move ext4-specific helpers into a separate common/ext4 file

Thanks,
Zorro

> 
>
Naohiro Aota Sept. 28, 2022, 3:57 a.m. UTC | #4
On Fri, Sep 23, 2022 at 07:51:26PM +0800, Zorro Lang wrote:
> On Fri, Sep 23, 2022 at 08:02:10AM +0000, Johannes Thumshirn wrote:
> > On 22.09.22 17:42, Zorro Lang wrote:
> > >> --- /dev/null
> > >> +++ b/common/zbd
> > > I don't like this abbreviation :-P If others don't open this file and read the
> > > comment in it, they nearly no chance to guess what's this file for.
> > > 
> > 
> > zbd is a well known abbreviation for zoned block devices. I think most
> > people in storage and filesystems know it.
> 
> OK, but we haven't been that "a single character is worth a thousand
> pieces of gold", so we can use a longer name, likes common/zone,
> common/zoned, common/zoned_block, common/zoned_device or something likes
> that. Anyway, that's just my personal opinion, if most of people prefer
> using "common/zbd", I'm fine to have that :) 

Sure. I'll use "zoned" as it is more common in the kernel code.

> But I hope you can move all zoned block device related helpers to the new
> common file if you'd like to bring in this file, likes what Darrick did in:
> 
> commit 67afd5c742464607994316acb2c6e8303b8af4c5
> Author: Darrick J. Wong <djwong@kernel.org>
> Date:   Tue Aug 9 14:00:46 2022 -0700
> 
>     common/rc: move ext4-specific helpers into a separate common/ext4 file

Yes, that will be better to have things in common/zoned. I considered
moving zoned functions (_zone_type, _require_{,non_}zoned_device), but
_require_loop() and _require_dm_target() use _require_non_zoned_device() in
them. So, moving _require_non_zoned_device() will make a dependency from
common/rc to common/zoned, which I considered not much clean. How do you
think of it?

Moving _filter_blkzone_report() would be fine, though.

> Thanks,
> Zorro
> 
> > 
> > 
>
Zorro Lang Sept. 28, 2022, 5:47 a.m. UTC | #5
On Wed, Sep 28, 2022 at 03:57:08AM +0000, Naohiro Aota wrote:
> On Fri, Sep 23, 2022 at 07:51:26PM +0800, Zorro Lang wrote:
> > On Fri, Sep 23, 2022 at 08:02:10AM +0000, Johannes Thumshirn wrote:
> > > On 22.09.22 17:42, Zorro Lang wrote:
> > > >> --- /dev/null
> > > >> +++ b/common/zbd
> > > > I don't like this abbreviation :-P If others don't open this file and read the
> > > > comment in it, they nearly no chance to guess what's this file for.
> > > > 
> > > 
> > > zbd is a well known abbreviation for zoned block devices. I think most
> > > people in storage and filesystems know it.
> > 
> > OK, but we haven't been that "a single character is worth a thousand
> > pieces of gold", so we can use a longer name, likes common/zone,
> > common/zoned, common/zoned_block, common/zoned_device or something likes
> > that. Anyway, that's just my personal opinion, if most of people prefer
> > using "common/zbd", I'm fine to have that :) 
> 
> Sure. I'll use "zoned" as it is more common in the kernel code.
> 
> > But I hope you can move all zoned block device related helpers to the new
> > common file if you'd like to bring in this file, likes what Darrick did in:
> > 
> > commit 67afd5c742464607994316acb2c6e8303b8af4c5
> > Author: Darrick J. Wong <djwong@kernel.org>
> > Date:   Tue Aug 9 14:00:46 2022 -0700
> > 
> >     common/rc: move ext4-specific helpers into a separate common/ext4 file
> 
> Yes, that will be better to have things in common/zoned. I considered
> moving zoned functions (_zone_type, _require_{,non_}zoned_device), but
> _require_loop() and _require_dm_target() use _require_non_zoned_device() in
> them. So, moving _require_non_zoned_device() will make a dependency from
> common/rc to common/zoned, which I considered not much clean. How do you
> think of it?

Oh, below commit [1] brought in the coupling of common/rc and zoned helpers.
Hmm... that cause all the 3 helpers (_zone_type, _require_{,non_}zoned_device)
have to be in common/rc or be imported in common/rc. Looks like we have to
keep them in common/rc, except we make a bigger refactor to common/rc, or you'd
like to make your 2 new helpers in common/rc too (likes these 3 old ones:)

BTW I doubt if we might need to use more zoned related helpers in common/rc, due
to we deal with test devices in common/rc mostly, likes dax. Someone might want
a seperated common/dax or common/pmem file one day. The common/rc imports
specific fs helpers according to $FSTYP (common/config: _source_specific_fs()).
If we need to deal with different kind of device types in common/rc one day, is
there a better idea to determine which one should be imported? Welcome any
suggestions if anyone has :)

[1]
commit 952310a57d9323ae0bb174b50be93107a8895e0c
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Mon Aug 16 20:35:08 2021 +0900

    common: add zoned block device checks

> 
> Moving _filter_blkzone_report() would be fine, though.

Yeah, moving this is fine.

Thanks,
Zorro

> 
> > Thanks,
> > Zorro
> > 
> > > 
> > > 
> > 
>
Darrick J. Wong Sept. 28, 2022, 3:32 p.m. UTC | #6
On Wed, Sep 28, 2022 at 01:47:15PM +0800, Zorro Lang wrote:
> On Wed, Sep 28, 2022 at 03:57:08AM +0000, Naohiro Aota wrote:
> > On Fri, Sep 23, 2022 at 07:51:26PM +0800, Zorro Lang wrote:
> > > On Fri, Sep 23, 2022 at 08:02:10AM +0000, Johannes Thumshirn wrote:
> > > > On 22.09.22 17:42, Zorro Lang wrote:
> > > > >> --- /dev/null
> > > > >> +++ b/common/zbd
> > > > > I don't like this abbreviation :-P If others don't open this file and read the
> > > > > comment in it, they nearly no chance to guess what's this file for.
> > > > > 
> > > > 
> > > > zbd is a well known abbreviation for zoned block devices. I think most
> > > > people in storage and filesystems know it.
> > > 
> > > OK, but we haven't been that "a single character is worth a thousand
> > > pieces of gold", so we can use a longer name, likes common/zone,
> > > common/zoned, common/zoned_block, common/zoned_device or something likes
> > > that. Anyway, that's just my personal opinion, if most of people prefer
> > > using "common/zbd", I'm fine to have that :) 
> > 
> > Sure. I'll use "zoned" as it is more common in the kernel code.
> > 
> > > But I hope you can move all zoned block device related helpers to the new
> > > common file if you'd like to bring in this file, likes what Darrick did in:
> > > 
> > > commit 67afd5c742464607994316acb2c6e8303b8af4c5
> > > Author: Darrick J. Wong <djwong@kernel.org>
> > > Date:   Tue Aug 9 14:00:46 2022 -0700
> > > 
> > >     common/rc: move ext4-specific helpers into a separate common/ext4 file
> > 
> > Yes, that will be better to have things in common/zoned. I considered
> > moving zoned functions (_zone_type, _require_{,non_}zoned_device), but
> > _require_loop() and _require_dm_target() use _require_non_zoned_device() in
> > them. So, moving _require_non_zoned_device() will make a dependency from
> > common/rc to common/zoned, which I considered not much clean. How do you
> > think of it?
> 
> Oh, below commit [1] brought in the coupling of common/rc and zoned helpers.
> Hmm... that cause all the 3 helpers (_zone_type, _require_{,non_}zoned_device)
> have to be in common/rc or be imported in common/rc. Looks like we have to
> keep them in common/rc, except we make a bigger refactor to common/rc, or you'd
> like to make your 2 new helpers in common/rc too (likes these 3 old ones:)
> 
> BTW I doubt if we might need to use more zoned related helpers in common/rc, due
> to we deal with test devices in common/rc mostly, likes dax. Someone might want
> a seperated common/dax or common/pmem file one day. The common/rc imports
> specific fs helpers according to $FSTYP (common/config: _source_specific_fs()).
> If we need to deal with different kind of device types in common/rc one day, is
> there a better idea to determine which one should be imported? Welcome any
> suggestions if anyone has :)

Leave those three in common/rc and put/move the rest to common/zoned ?

I think it's fine for common/rc to have helpers that *detect* the
presence of a blockdev feature, and require tests to source
common/$feature if they want to do anything clever with that feature.
After all, the _require_non_zoned_device tests don't care about
_zone_capacity, right?

--D

> [1]
> commit 952310a57d9323ae0bb174b50be93107a8895e0c
> Author: Naohiro Aota <naohiro.aota@wdc.com>
> Date:   Mon Aug 16 20:35:08 2021 +0900
> 
>     common: add zoned block device checks
> 
> > 
> > Moving _filter_blkzone_report() would be fine, though.
> 
> Yeah, moving this is fine.
> 
> Thanks,
> Zorro
> 
> > 
> > > Thanks,
> > > Zorro
> > > 
> > > > 
> > > > 
> > > 
> > 
>
Naohiro Aota Sept. 29, 2022, 2:40 a.m. UTC | #7
On Wed, Sep 28, 2022 at 08:32:47AM -0700, Darrick J. Wong wrote:
> On Wed, Sep 28, 2022 at 01:47:15PM +0800, Zorro Lang wrote:
> > On Wed, Sep 28, 2022 at 03:57:08AM +0000, Naohiro Aota wrote:
> > > On Fri, Sep 23, 2022 at 07:51:26PM +0800, Zorro Lang wrote:
> > > > On Fri, Sep 23, 2022 at 08:02:10AM +0000, Johannes Thumshirn wrote:
> > > > > On 22.09.22 17:42, Zorro Lang wrote:
> > > > > >> --- /dev/null
> > > > > >> +++ b/common/zbd
> > > > > > I don't like this abbreviation :-P If others don't open this file and read the
> > > > > > comment in it, they nearly no chance to guess what's this file for.
> > > > > > 
> > > > > 
> > > > > zbd is a well known abbreviation for zoned block devices. I think most
> > > > > people in storage and filesystems know it.
> > > > 
> > > > OK, but we haven't been that "a single character is worth a thousand
> > > > pieces of gold", so we can use a longer name, likes common/zone,
> > > > common/zoned, common/zoned_block, common/zoned_device or something likes
> > > > that. Anyway, that's just my personal opinion, if most of people prefer
> > > > using "common/zbd", I'm fine to have that :) 
> > > 
> > > Sure. I'll use "zoned" as it is more common in the kernel code.
> > > 
> > > > But I hope you can move all zoned block device related helpers to the new
> > > > common file if you'd like to bring in this file, likes what Darrick did in:
> > > > 
> > > > commit 67afd5c742464607994316acb2c6e8303b8af4c5
> > > > Author: Darrick J. Wong <djwong@kernel.org>
> > > > Date:   Tue Aug 9 14:00:46 2022 -0700
> > > > 
> > > >     common/rc: move ext4-specific helpers into a separate common/ext4 file
> > > 
> > > Yes, that will be better to have things in common/zoned. I considered
> > > moving zoned functions (_zone_type, _require_{,non_}zoned_device), but
> > > _require_loop() and _require_dm_target() use _require_non_zoned_device() in
> > > them. So, moving _require_non_zoned_device() will make a dependency from
> > > common/rc to common/zoned, which I considered not much clean. How do you
> > > think of it?
> > 
> > Oh, below commit [1] brought in the coupling of common/rc and zoned helpers.
> > Hmm... that cause all the 3 helpers (_zone_type, _require_{,non_}zoned_device)
> > have to be in common/rc or be imported in common/rc. Looks like we have to
> > keep them in common/rc, except we make a bigger refactor to common/rc, or you'd
> > like to make your 2 new helpers in common/rc too (likes these 3 old ones:)
> > 
> > BTW I doubt if we might need to use more zoned related helpers in common/rc, due
> > to we deal with test devices in common/rc mostly, likes dax. Someone might want
> > a seperated common/dax or common/pmem file one day. The common/rc imports
> > specific fs helpers according to $FSTYP (common/config: _source_specific_fs()).
> > If we need to deal with different kind of device types in common/rc one day, is
> > there a better idea to determine which one should be imported? Welcome any
> > suggestions if anyone has :)
> 
> Leave those three in common/rc and put/move the rest to common/zoned ?
> 
> I think it's fine for common/rc to have helpers that *detect* the
> presence of a blockdev feature, and require tests to source
> common/$feature if they want to do anything clever with that feature.
> After all, the _require_non_zoned_device tests don't care about
> _zone_capacity, right?

Thank you for your suggestions. Yes, _require_non_zoned_device() just read
/sys/block/${sdev}/queue/zoned. I'll do so to leave the three functions in
common/rc and move/create other helpers in common/zoned.

Thanks,

> --D
> 
> > [1]
> > commit 952310a57d9323ae0bb174b50be93107a8895e0c
> > Author: Naohiro Aota <naohiro.aota@wdc.com>
> > Date:   Mon Aug 16 20:35:08 2021 +0900
> > 
> >     common: add zoned block device checks
> > 
> > > 
> > > Moving _filter_blkzone_report() would be fine, though.
> > 
> > Yeah, moving this is fine.
> > 
> > Thanks,
> > Zorro
> > 
> > > 
> > > > Thanks,
> > > > Zorro
> > > > 
> > > > > 
> > > > > 
> > > > 
> > > 
> >
diff mbox series

Patch

diff --git a/common/zbd b/common/zbd
new file mode 100644
index 000000000000..329bb7be6b7b
--- /dev/null
+++ b/common/zbd
@@ -0,0 +1,17 @@ 
+#
+# Common zoned block device specific functions
+#
+
+. common/filter
+
+_zone_capacity() {
+    local phy=$1
+    local dev=$2
+
+    [ -z "$dev" ] && dev=$SCRATCH_DEV
+
+    size=$($BLKZONE_PROG report -o $phy -l 1 $dev |\
+	       _filter_blkzone_report |\
+	       grep -Po "cap 0x[[:xdigit:]]+" | cut -d ' ' -f 2)
+    echo $((size << 9))
+}
diff --git a/tests/btrfs/237 b/tests/btrfs/237
index bc6522e2200a..101094b5ce70 100755
--- a/tests/btrfs/237
+++ b/tests/btrfs/237
@@ -13,7 +13,7 @@ 
 _begin_fstest auto quick zone balance
 
 # Import common functions.
-. ./common/filter
+. ./common/zbd
 
 # real QA test starts here
 
@@ -56,11 +56,7 @@  fi
 
 start_data_bg_phy=$(get_data_bg_physical)
 start_data_bg_phy=$((start_data_bg_phy >> 9))
-
-size=$($BLKZONE_PROG report -o $start_data_bg_phy -l 1 $SCRATCH_DEV |\
-	_filter_blkzone_report |\
-	grep -Po "cap 0x[[:xdigit:]]+" | cut -d ' ' -f 2)
-size=$((size << 9))
+size=$(_zone_capacity $start_data_bg_phy)
 
 reclaim_threshold=75
 echo $reclaim_threshold > /sys/fs/btrfs/"$uuid"/bg_reclaim_threshold