From: Richard Weinberger <richard@sigma-star.at>
To: linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org
Cc: Richard Weinberger <richard@nod.at>,
kch@nvidia.com, sagi@grimberg.me, hch@lst.de,
upstream+nvme@sigma-star.at, Damien Le Moal <dlemoal@kernel.org>
Subject: Re: [RFC PATCH] nvmet: Make blksize_shift configurable
Date: Fri, 18 Apr 2025 11:56:30 +0200 [thread overview]
Message-ID: <8418057.aG60p0z9Xu@anvil> (raw)
In-Reply-To: <0e61c6e9-10bc-4272-b446-31e0d67547ce@kernel.org>
On Freitag, 18. April 2025 11:37 'Damien Le Moal' via upstream wrote:
> > + if (!ns->blksize_shift)
> > + ns->blksize_shift = blksize_bits(bdev_logical_block_size(ns->bdev));
>
> If the user set logical block size is smaller than the block dev logical block
> size, this is not going to work... No ? Am I missing something ?
Likely, yes.
TBH, I'm not sure whether it makes actually sense for the bdev case to make
blksize_shift configurable.
The case I see most benefit is the backing file case.
> > + if (!ns->blksize_shift) {
> > + /*
> > + * i_blkbits can be greater than the universally accepted
> > + * upper bound, so make sure we export a sane namespace
> > + * lba_shift.
> > + */
> > + ns->blksize_shift = min_t(u8,
> > + file_inode(ns->file)->i_blkbits, 12);
>
> This will work for any block size, regardless of the FS block size, but only if
> ns->buffered_io is true. Doesn't this require some more checks with regards to
> O_DIRECT (!ns->buffered_io case) ?
Good catch. I'll add a check.
It's also worth discussing whether we should limit blksize_shift to a specific
range. Right now, any shift is accepted, and it is up to the user to
use a sane value.
Thanks,
//richard
--
sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
ATU 66964118 | FN: 374287y
next prev parent reply other threads:[~2025-04-18 10:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-18 9:08 [RFC PATCH] nvmet: Make blksize_shift configurable Richard Weinberger
2025-04-18 9:37 ` Damien Le Moal
2025-04-18 9:56 ` Richard Weinberger [this message]
2025-04-18 10:23 ` Damien Le Moal
2025-04-18 10:53 ` Richard Weinberger
2025-04-22 8:16 ` Christoph Hellwig
2025-04-22 6:47 ` Chaitanya Kulkarni
2025-04-22 6:50 ` Chaitanya Kulkarni
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=8418057.aG60p0z9Xu@anvil \
--to=richard@sigma-star.at \
--cc=dlemoal@kernel.org \
--cc=hch@lst.de \
--cc=kch@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=richard@nod.at \
--cc=sagi@grimberg.me \
--cc=upstream+nvme@sigma-star.at \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.