From: Christoph Hellwig <hch@lst.de>
To: Hannes Reinecke <hare@suse.de>
Cc: Christoph Hellwig <hch@lst.de>, Hannes Reinecke <hare@kernel.org>,
Keith Busch <kbusch@kernel.org>, Sagi Grimberg <sagi@grimberg.me>,
linux-nvme@lists.infradead.org,
Abdulla Nasirli <nasirabd@fit.cvut.cz>
Subject: Re: [PATCHv2] nvmet: lift blocksize restriction to 64k
Date: Fri, 20 Feb 2026 17:45:30 +0100 [thread overview]
Message-ID: <20260220164530.GB15907@lst.de> (raw)
In-Reply-To: <8d50557c-86a8-4364-b5e7-d40b36ad9f60@suse.de>
On Fri, Feb 20, 2026 at 05:42:25PM +0100, Hannes Reinecke wrote:
> On 2/20/26 16:32, Christoph Hellwig wrote:
>> On Fri, Feb 20, 2026 at 04:12:59PM +0100, Hannes Reinecke wrote:
>>> With commit 47dd67532303 ("block/bdev: lift block size restrictions to 64k")
>>> we can now support up to 64k block sizes, so lift the restriction on 4k for
>>> file-backed namespaces.
>>
>> Still not sure this is a great idea by default. Yes, modern Linux supports
>> 64k sector sizes, but even then just for a few file systems. And this
>> changes existing setups, which will now break when upgrading the kernel.
>>
> How so? There cannot be any existing nvmet setup with an LBS backing
> device, as the device will be rejected when trying to setup the target.
> Which breakage do you see here?
There can be a setup with a large i_blkbits that we limit to 4k
export LBA size right now, and with your patch it will be exposed
as something larger.
next prev parent reply other threads:[~2026-02-20 16:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-20 15:12 [PATCHv2] nvmet: lift blocksize restriction to 64k Hannes Reinecke
2026-02-20 15:32 ` Christoph Hellwig
2026-02-20 16:42 ` Hannes Reinecke
2026-02-20 16:45 ` Christoph Hellwig [this message]
2026-02-23 7:44 ` Hannes Reinecke
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=20260220164530.GB15907@lst.de \
--to=hch@lst.de \
--cc=hare@kernel.org \
--cc=hare@suse.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=nasirabd@fit.cvut.cz \
--cc=sagi@grimberg.me \
/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