On Tue, Nov 13, 2018 at 03:52:17PM -0500, John Ferlan wrote:
[...]
>>
>> I understand (generically) why we need the lock. I'm OK with it being
>> enabled by default. That's not the question/ask. Building in a way to
>> allow disabling usage of virFork and/or metadata lock knowing the
>> "penalty" or downside to doing so goes beyond bug free or
performance,
>> it's just that "choice" we allow someone to make. You know there
are
>> those out there that will bemoan "choosing" this is as the default.
If
>> they want to disable in order to gain whatever at the cost of something
>> else, then so be it. In some ways it's a CYA exercise.
>
> Just an idea that I got, what if there won't be any config knob but this
> would use namespaces? I mean, if namespaces are on then metadata locking
> is happening and if they are off then no metadata locking is happening.
>
> Since namespaces do mean extra fork(), doing things this way there won't
> be any extra fork() if namespaces are off.
>
I'd prefer to not make metadata locking (files) rely on namespaces
(devices). I get the relationship though.
In particular the needs for metadata locking applies to all platforms
that libvirt QEMU driver runs on (*BSD, OSX), but namespaces only
work on Linux.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|