[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Mon, Sep 02, 2024 at 03:50:05PM +0000, Anthony PERARD wrote:
> 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.
>          ...

While this is what the protocol specification says, just look how
different implementations have managed to diverge in all kind of
different ways.  I wouldn't discard there's a frontend somewhere that
exposes `feature-large-sector-size` without doing the calculations as
stated in the specification.

> 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.

Yeah, that's the intention, to mark `feature-large-sector-size` as
deprecated in blkif.h and note it shouldn't be exposed by frontends.

I however wasn't planning to change Linux blkback for example to
refuse to attach to frontends that expose `feature-large-sector-size`
when `sector-size` != 512.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.