linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Zorro Lang <zlang@redhat.com>
Cc: Naohiro Aota <Naohiro.Aota@wdc.com>,
	Johannes Thumshirn <Johannes.Thumshirn@wdc.com>,
	"fstests@vger.kernel.org" <fstests@vger.kernel.org>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH 1/2] common: introduce zone_capacity() to return a zone capacity
Date: Wed, 28 Sep 2022 08:32:47 -0700	[thread overview]
Message-ID: <YzRpH5SvkKwhlELi@magnolia> (raw)
In-Reply-To: <20220928054715.ol6gammnf6jmrjab@zlang-mailbox>

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
> > > 
> > > > 
> > > > 
> > > 
> > 
> 

  reply	other threads:[~2022-09-28 15:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-22  5:54 [PATCH 0/2] btrfs: test active zone tracking Naohiro Aota
2022-09-22  5:54 ` [PATCH 1/2] common: introduce zone_capacity() to return a zone capacity Naohiro Aota
2022-09-22 15:41   ` Zorro Lang
2022-09-23  8:02     ` Johannes Thumshirn
2022-09-23 11:51       ` Zorro Lang
2022-09-28  3:57         ` Naohiro Aota
2022-09-28  5:47           ` Zorro Lang
2022-09-28 15:32             ` Darrick J. Wong [this message]
2022-09-29  2:40               ` Naohiro Aota
2022-09-22  5:54 ` [PATCH 2/2] btrfs: test active zone tracking Naohiro Aota
2022-09-22 16:03   ` Zorro Lang
2022-09-28  3:58     ` Naohiro Aota
2022-09-22 12:18 ` [PATCH 0/2] " Johannes Thumshirn

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=YzRpH5SvkKwhlELi@magnolia \
    --to=djwong@kernel.org \
    --cc=Johannes.Thumshirn@wdc.com \
    --cc=Naohiro.Aota@wdc.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).