Re: Block protocol incompatibilities with 4K logical sector size disks

[Anthony PERARD <anthony.perard@vates.tech>]

On Mon, Sep 02, 2024 at 05:23:37PM +0200, Roger Pau Monné wrote:
> On Mon, Sep 02, 2024 at 03:19:56PM +0100, Paul Durrant wrote:
> > On 02/09/2024 09:55, Roger Pau Monné wrote:
> > [snip]
> > >
> > > Thanks for your input.  I would also like to hear from the blktap and
> > > Windows PV drivers maintainers, as the change that I'm proposing here
> > > will require changes to their implementations.
> > >
> >
> > So IIUC you are proposing to refuse to connect to a frontend that sets
> > feature-large-sector-size if sector-size != 512? Is that right?
>
> Is is worth retrofitting this into existing backends?  My suggestion
> would be to make `feature-large-sector-size` not mandatory to expose a
> sector-size != 512, but I wouldn't go as far as refusing to connect to
> frontends that expose the feature.  I have no idea which frontends
> might expose `feature-large-sector-size` but still be compatible with
> Linux blkback regarding sector-size != 512 (I know the Windows one
> isn't).

The frontend exposing "feature-large-sector-size" are not going to work
with Linux's backend if it set "sector-size" to a value different from
512.

From blkif.h:
    feature-large-sector-size
         A value of "1" indicates that the frontend will correctly supply and
         interpret all sector-based quantities in terms of the "sector-size"
         value supplied in the backend info, whatever that may be set to.
         ...

But Linux interprets "sector-based quantities" as 512 bytes. This is
incompatible with "feature-large-sector-size".

This is why I proposed to mark "feature-large-sector-size" as broken or
incompatible with your proposal to use 512B for all sector-based
quantities.

Cheers,

--

Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech