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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
