Re: [Xen-devel] [PATCH v2 0/2] xen-block: fix sector size confusion

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
[snip]
> > >
> > > The old implementation has the sector size hardcoded:
> > >
> > >     #define BLOCK_SIZE  512
> > >
> > > Whereas the qdevified version uses DEFINE_BLOCK_PROPERTIES(), which
> > > includes user-visible options for logical/physical_block_size.
> > >
> > > So before, you couldn't even define a different sector size and the
> > > question whether 512 or the sector size should be used didn't make a
> > > difference anyway.
> > >
> > > > If so, then I think it is fine for this series to state (much more
> > > > clearly than it does) that it is returning qemu's behaviour to match the
> > > > currently released version, because we've discovered an issue in the
> > > > spec/protocol, and that we will subsequently work address the issue in
> > > > the spec and provide a forwards path which doesn't involve nailing our
> > > > feet to the floor.
> > >
> > > The closest thing to returning to the old behaviour would be erroring
> > > out during device initialisation if logical_block_size != 512.
> >
> > One thing I've not figured out... If I create a blockdev in QEMU that
> > is pointing at a real device with a logical_block_size of 4k, will the
> > QEMU block layer perform the necessary read-modify-write cycles for
> > accesses < 4k? IOW would it be safe to always advertise a size of 512
> > to a frontend?
> 
> Yes, for 512 accesses on native 4k disks with O_DIRECT, the QEMU block
> layer performs the necessary RMW. Of course, it still comes with a
> performance penalty, so you want to avoid such setups, but they do work.
> 

Ok, that's good. Thanks.

> > The problem with erroring out during device init is that it does not
> > give us a way of fixing things in future, as the frontend has not
> > started at that time and thus we'd have no idea whether it could use
> > whatever protocol fix we come up with. I think the only thing the
> > backend could do is refuse to connect to an old frontend if
> > logical_block_size != 512.
> 
> I was just thinking of getting back to the old state, with a quick fix
> (by making the problematic new setting inaccessible) for the bug in 4.0
> that could possible be merged today or tomorrow for rc2.
> 

Ok, I see what you mean. I'll modify and resubmit patch #1 today.

> What you need to do for actually supporting 4k disks in the long term
> (QEMU 4.1 or later) depends on what the drivers look like currently and
> is a separate discussion.
> 

Yes, agreed.

  Paul

> Kevin

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