Re: [Qemu-block] [Qemu-devel] [PATCH v15 21/21] qemu-iotests: Add test case 153 for image locking

[Fam Zheng]

On Thu, 04/27 11:05, Kevin Wolf wrote:
> Am 27.04.2017 um 03:32 hat Fam Zheng geschrieben:
> > On Wed, 04/26 16:49, Kevin Wolf wrote:
> > > Am 26.04.2017 um 05:34 hat Fam Zheng geschrieben:
> > > > Signed-off-by: Fam Zheng <address@hidden>
> > > 
> > > I'll do the actual review of the test case later, but I already have a
> > > question... Can we find a way to accept the expected lock losses on
> > > systems without OFD? I'm using RHEL 7 as my main development OS, so I
> > > wouldn't like having to deal with false positives there.
> > 
> > Split the lock loss cases to a separate case and _not_run? :)
> 
> You still need to find out from a shell script whether OFD locks are
> supported before you can call _not_run, but otherwise I'm fine with
> this.

OK. Shouldn't be rocket science. Let's try.

> 
> > > Hm... And actually, printing a warning will probably invalidate all the
> > > other reference outputs, too. After all, every single invocation of
> > > qemu/qemu-img/qemu-io will print a warning. Maybe that's a bit too much
> > > even for manual users when they can't do anything about it (which is
> > > unlike the format probing warning that you can get rid of by simply
> > > changing your command line).
> > 
> > An idea: make locking=on/off/auto, and auto is on iff OFD is usable,
> > otherwise off. When user specifies locking=on but OFD is unusable, we
> > print a warning.
> > 
> > Only in this on test case the warning will be printed on RHEL, and
> > it's easy to filter it out.
> 
> So POSIX locks only if you explicitly enable locking? It would be a pity
> to do even less than we could theoretically do by default, but at least
> the default wouldn't result in surprising behaviour by losing locks
> randomly.
> 
> The argument for it would be that being consistently unsafe is better
> than being unpredictably safe or unsafe. I always find this kind of
> decision hard to make because I can appreciate both sides of the
> argument.

For purists, consistency is perhaps more important; for pragmatists, some
protection is better than none. I figure it's up to the right of maintainers,
which you are.  :)

However I do think making noticable complaints about OFD missing (in the
documentation and/or the error messages) is of greater good, and is better than
silent yet incomplete safty.

We want to offer as much protection as possible to everyone but it's more
important when there is a qcow2 corruption report (I hope there isn't :) in the
future, we can be sure whether locking is in place or not, no iffy situation.
POSIX locking makes this harder, a warning message is helpful.

Fam