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 :|