Apologies - I made the mistake of thinking Ubuntu launchpad was actually functional, as it is I think they simply throw messages on there back to the original mailing list!
On Wed, 25 May 2016 at 12:14 Greg Kurz <gk...@linux.vnet.ibm.com> wrote: > On Thu, 05 May 2016 20:54:31 -0000 > Server Angels <ad...@serverangels.co.uk> wrote: > > I would appreciate this patch being committed as I *think* it's > > affecting a system i'm building now. > > > > I have a backup host with 2 VMs. For business reasons they need to be > > network isolated from each other and the host, so each is passed through > > a physical NIC. Each VM does need access to a variable size datastore on > > the host so I am using virtfs /9p to expose a mountpoint to each VM. > > > > The VMs each backup servers to their respective mountpoint to this > > virtfs mount using rsync. Just backing up one server with ~4000 files > > and 3 large sparse VM images saw the open files on the backup host > > increase to over *800000* and the rsync progressively get slower. > > Shutting down these VMs then takes hours as it can't unlock the files it > > has open on the backup host. > > > > I understand rsync does use open-unlink-fstat extensively, hence why I > > think this is the issue. > > > > This is a deal breaker for any production use of virtfs. Does anybody > > know if this is fixed in other builds of qemu? > > > > tl;dr - to recreate this on 16.04 - create a VM with a virtfs/9p mount > > to the host. Do lots of rsyncs to this mount within the VM, watch 'lsof > > | wc -l' go higher and higher on the host. > > > > Thanks, > > > > /Sean > > > > Hi Sean ! > > I've just stumbled upon this mail... maybe worth to post directly to > qemu-devel and Cc: 9p maintainers next time :) > > "Aneesh Kumar K.V" <aneesh.ku...@linux.vnet.ibm.com> (supporter:virtio-9p) > Greg Kurz <gk...@linux.vnet.ibm.com> (supporter:virtio-9p) > > I'm now catching up on the background for this issue. > > Cheers. > > -- > Greg > >
