Re: [Xen-devel] [PATCH] public/io/blkif.h: make the comments on "sectors" self-consistent

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Anthony PERARD [mailto:anthony.perard@xxxxxxxxxx]
> Sent: 21 March 2019 17:23
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Konrad Rzeszutek Wilk 
> <konrad.wilk@xxxxxxxxxx>
> Subject: Re: [Xen-devel] [PATCH] public/io/blkif.h: make the comments on 
> "sectors" self-consistent
> 
> > > I think this is how the currents implementations are working:
> > >     media/disk size = "sectors" * "sector-size"
> > > then, "sectors" and "sector-size" are never used again.
> >
> > Not true, unfortunately. At least the Windows frontends are (mis)coded to 
> > use sector numbers
> directly in blkif_request_t and blkif_request_segment rather than re-scaling 
> to 512 bytes, so setting
> sector-size != 512 will certainly make them misbehave according to the 
> protocol. This can, of course,
> be fixed but I think we're at point where the only safe way to set a larger 
> sector-size would be to
> have the frontend write an 'I'm not broken' flag into xenstore that the 
> backend reads before setting
> sector-size (and if that means that the backend has to do read-modify-write 
> cycles for an underlying
> storage device with a larger logical block size then so be it).
> 
> So, hard-coding "sector-size" to 512 in blkif.h sound good to me.

Ok, I'll send a v2 that does that. I think it best if I also include a 
specification my proposed 'I'm not broken' flag so a frontend can enable a 
backend to set a non-512 sector size.

  Paul

> 
> --
> Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel