Re: [PATCH v2] docs: document file-posix locking protocol

["Denis V. Lunev" <den@openvz.org>]

On 7/5/21 10:55 AM, Vladimir Sementsov-Ogievskiy wrote:
> 03.07.2021 17:50, Nir Soffer wrote:
>> On Sat, Jul 3, 2021 at 4:51 PM Vladimir Sementsov-Ogievskiy
>> <vsementsov@virtuozzo.com> wrote:
>>>
>>> Let's document how we use file locks in file-posix driver, to allow
>>> external programs to "communicate" in this way with Qemu.
>>
>> This makes the locking implementation public, so qemu can never change
>> it without breaking external programs. I'm not sure this is an issue
>> since
>> even now qemu cannot change without breaking compatibility with older
>> qemu versions.
>
> Yes, that's my thought too. I think, that's enough to say that we
> actually have "public" protocol, just undocumented.
>
> Note, that breaking that compatibility may break shared migration, and
> migration without one host (which may be used for live upgrade of qemu).
>
>>
>> Maybe a better way to integrate with external programs is to provide
>> a library/tool to perform locking?
>>
>> For example we can have tool like:
>>
>>     qemu-img lock [how] image command
>>
>> This example will take the lock specified by "how" on image while
>> "command"
>> is running.
>
> Having a parallel process, that takes locks "for us" is a pain. At
> least we should handle unexpected death of that process. Some
> filesystems may not allow opening file in two processes in some
> circumstances. And it just breaks normal operation with file locks:
> lock should be taken by the process that use it.
>
> Library has GPL limitation of use.

and there are also some important consequences. 3rd party implements
QCOW2 support in a 3rd party way. Thus it opens the image and creates
3rd party data structures for it.

It handles metadata processing etc. Thus once the "locking" library will
be ready to operate, some bits indicating that the image is in use would
be on the filesystem, f.e. "busy" state and thus we would need to perform
the "locking" in QEMU code through a very specific QEMU data structure
creation. The library could do locking first, but in that case 3rd party
code would have same problems.

In general, this is not only QCOW2 problem, such locking is a problem
for all supported formats and thus we come to the dilemma:
- to document
- or to provide an utility
In that case we should provide locking for all "alien" formats, which
is looking overcomplicated at my opinion.

In general, the format itself is opened with providing the information
for all 3rd parties to integrate with. The locking is an important part
of interoperability and thus should be published too.

Den