Re: [PATCH v2] nvmet: Make blksize_shift configurable

[Richard Weinberger <richard@sigma-star.at>]

On Dienstag, 1. Juli 2025 09:32 Damien Le Moal wrote:
> > The initial intention of this patch was exposing the blksize_shift property.
> > If we want to expose this as more user friendly, I'm fine with it.
> > Maybe "minimum_io_size"?
> 
> That likely will be confusing with the existing device limit io_min. I think
> block_size is clear.

Ok!

> > 
> >> 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'm not sure whether it's worth putting more smartness into this logic.
> 
> This may be nice to avoid users shooting themselves in the foot with a bad
> setup and us having to deal with bad performance complaints...
> If we do not do anything special, we will be stuck with it as a more
> restrictive setup later may break some (bad) user setups. That is why I raised
> the point :)

Detecting whether the backend is an HDD should work via bdev_nonrot().
So, we could issue a warning if bdev_nonrot() is true and the configured
block size is less than bdev_physical_block_size()?

> >> 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 ?
> > 
> > I was not sure about that.
> > Is it guaranteed that STATX_DIOALIGN returns something sane?
> 
> If it is defined by the FS, yes. But it may not be defined, so in that case,
> you have to use the fallback of the bdev block size.

Ok!

LG,
//richard

-- 
​​​​​sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
ATU 66964118 | FN: 374287y