public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: "hch@infradead.org" <hch@infradead.org>
To: Sean Anderson <seanga2@gmail.com>
Cc: "hch@infradead.org" <hch@infradead.org>,
	Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: [PATCH blktests] zbd/005: Limit block size to zone length
Date: Fri, 25 Apr 2025 06:47:14 -0700	[thread overview]
Message-ID: <aAuSYhnxwpJns5Cs@infradead.org> (raw)
In-Reply-To: <790260c8-09b4-96b3-310f-f9c5a93ef7ff@gmail.com>

On Fri, Apr 25, 2025 at 12:04:39AM -0400, Sean Anderson wrote:
> and in userspace that assumes 512-byte granularity. But there is no
> such deeply-ingrained assumption for zones. You just have to set the
> parameter correctly.

There are everywhere in software actually using zones.  You still
haven't answered whay your intended use case is, btw.

> Plus, smaller zones are more efficient at reducing write amplification,
> in the same way as smaller block sizes.

No, they aren't.  If you zones are only a few kb you will waste a lot
of effort to actually track their state.

> If you really think such zone sizes should not be supported, then go
> add such a restriction to all the zone standards.

The zoned standards are extremely lax in what they allow, that is by
intent.  Actually software supports a lot less, and that for a good
reason,

> > Yes, it would be nice to have a sanity check for that and reject it
> > early, but no one is going to rewrite tests to remove that "assumption".
> 
> This assumption is very weak. It can easily be removed.

It can, but it's a really bad idea.

We're running in circles.  You are doing something very silly with
something not support in the kernel right now, without a use case
and are lecturing people who've done zoned software for years with
made up falsehoods.  That's not going very well.  Maybe your clever
scheme actually is better than what everyone has done for years, but
you'd better explain it very well and show how it's actually going
to work.

  reply	other threads:[~2025-04-25 13:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-23 16:49 [PATCH blktests] zbd/005: Limit block size to zone length Sean Anderson
2025-04-24  8:09 ` Christoph Hellwig
2025-04-24 11:30   ` Shinichiro Kawasaki
2025-04-24 13:56     ` Sean Anderson
2025-04-24 14:06       ` hch
2025-04-24 14:20         ` Sean Anderson
2025-04-24 14:23           ` hch
2025-04-25  4:04             ` Sean Anderson
2025-04-25 13:47               ` hch [this message]
2025-04-26  5:23                 ` Sean Anderson
2025-04-27  3:23                   ` Keith Busch
2025-04-25  2:37     ` Damien Le Moal

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=aAuSYhnxwpJns5Cs@infradead.org \
    --to=hch@infradead.org \
    --cc=linux-block@vger.kernel.org \
    --cc=seanga2@gmail.com \
    --cc=shinichiro.kawasaki@wdc.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