Re: [virtio] [PATCH] virtio-blk: restore VIRTIO_BLK_F_FLUSH and VIRTIO_BLK_F_CONFIG_WCE

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jul 08, 2015 at 01:04:40PM +0200, Paolo Bonzini wrote:
> 
> 
> On 08/07/2015 12:53, Michael S. Tsirkin wrote:
> >>> Below 2 paragraphs tell you why :)
> >>> Because it does not always *have* non-volatile storage.
> >>
> >> So are we still discussing what MUST means?
> > 
> > I'm discussing what non-volatile means.
> 
> Since we're down to just 1 or 2 contentious points, I'm sending v4.
> Let's reboot the discussion on top of that version.  Just a couple
> comments below:
> 
> >> If the guest cannot see the
> >> difference, QEMU is not violating anything.
> > 
> > Of course it can see the difference after reset.
> 
> Not after reset, only after a cold restart (there was a
> crash---restoring from migration).  A lot more changes could happen
> between shutdown (doesn't matter if clean or crashy) and the next cold
> restart, and the guest can detect them the same way.
> 
> E.g. in one case the guest could detect that the kernel was updated via
> libguestfs.  In another the guest could detect that the storage
> (formerly in tmpfs, though the guest didn't know that) is now all zero.

Absolutely. I think this means we can't say "spec tells device MUST NOT
lose data, but qemu loses it and that is ok since no one ever can
observe that". It's observable, and if it's sometimes okay,
appropriate statement is SHOULD NOT lose data.


> >> If they don't, they've already done something not recommended, and a MAY
> >> is just fine in this paragraph.  This paragraph only applies to
> >> implementation that have already disregarded that other "SHOULD".  It
> >> makes little sense to do yet another recommendation that they would
> >> disregard.
> >>
> >> This "MAY" is here to explicitly allow the behavior.
> > 
> > Well ignoring that SHOULD leads to bad performance, ignoring
> > this one leads to data loss. So you need to pause and think
> > at both points ...
> 
> I see your point.  However, whoever ignores that SHOULD is very likely
> not caring about data safety anyway.  This MAY allows them to keep the
> data safe at the price of bad performance, in the unlikely case that
> they do care about data safety.
> 
> Paolo

Looks like I was unclear.  What I was suggesting is reversing the
case. Asking that data SHOULD be safe.

-- 
MST