From: Richard Weinberger <richard@sigma-star.at>
To: Damien Le Moal <dlemoal@kernel.org>, upstream@sigma-star.at
Cc: Richard Weinberger <richard@nod.at>,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
kch@nvidia.com, sagi@grimberg.me, hch@lst.de,
upstream+nvme@sigma-star.at, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v2] nvmet: Make blksize_shift configurable
Date: Thu, 03 Jul 2025 11:29:58 +0200 [thread overview]
Message-ID: <2880421.FSEd18e0ET@nailgun> (raw)
In-Reply-To: <20250703085451.GA4459@lst.de>
On Donnerstag, 3. Juli 2025 10:54 Christoph Hellwig wrote:
> On Tue, Jul 01, 2025 at 09:34:00AM +0900, Damien Le Moal wrote:
> > Even if internally you use the block size bit shift, I think it would be better
> > if the user facing interface is the block size as that is much easier to
> > manipulate without having to remember the exponent for powers of 2 values :)
>
> Yeah, block sizes are probably a nice user interface indeed.
Ok!
>
> > pr_err("Configured blksize needs to be at least %u for device %s\n",
> > bdev_logical_block_size(ns->bdev),
> > ns->device_path);
> > return -EINVAL;
> > }
> >
> > Also, if the backend is an HDD, do we want to allow the user to configure a
> > block size that is less than the *physical* block size ? Performance will
> > suffer on regular HDDs and writes may fail with SMR HDDs.
>
> I don't think we should babysit the user like that, just like we allow
> creating file systems with block size smaller than the physical block
> size.
I'm fine with either way.
>
> > > + if (!vfs_getattr(&ns->file->f_path, &st, STATX_DIOALIGN, 0) &&
> > > + (st.result_mask & STATX_DIOALIGN) &&
> > > + (1 << ns->blksize_shift) < st.dio_offset_align)
> > > + return -EINVAL;
> > > +
> > > + if (sb_bdev && (1 << ns->blksize_shift < bdev_logical_block_size(sb_bdev)))
> > > + return -EINVAL;
> >
> > I am confused... This is going to check both... But if you got STATX_DIOALIGN
> > and it is OK, you do not need (and probably should not) do the second if, no ?
> >
> > Also, the second condition of the second if is essentially the same check as
> > for the block dev case. So maybe reuse that by creating a small helper function ?
>
> This code is copy and pasted from loop, so it's originally my fault.
> It just missed the comment that explains why it is there:
>
> /*
> * In a perfect world this wouldn't be needed, but as of Linux 6.13 only
> * a handful of file systems support the STATX_DIOALIGN flag.
> */
Well, my code is the other way around. I checks the logical block size of a device
even if STATX_DIOALIGN succeeded, which is a bit too paranoid I guess.
Thanks,
//richard
--
sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
ATU 66964118 | FN: 374287y
prev parent reply other threads:[~2025-07-03 9:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-30 19:13 [PATCH v2] nvmet: Make blksize_shift configurable Richard Weinberger
2025-07-01 0:34 ` Damien Le Moal
2025-07-01 7:09 ` Richard Weinberger
2025-07-01 7:32 ` Damien Le Moal
2025-07-01 15:00 ` Richard Weinberger
2025-07-03 8:54 ` Christoph Hellwig
2025-07-03 9:29 ` Richard Weinberger [this message]
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=2880421.FSEd18e0ET@nailgun \
--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 \
--cc=upstream@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.