Re: [Qemu-devel] [PATCH v7 0/3] 9p: Fix file ID collisions

From: Greg Kurz <groug@kaod.org>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>
Cc: "Stefan Hajnoczi" <stefanha@gmail.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	qemu-devel@nongnu.org,
	"Antonios Motakis" <antonios.motakis@huawei.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v7 0/3] 9p: Fix file ID collisions
Date: Tue, 8 Oct 2019 15:47:29 +0200	[thread overview]
Message-ID: <20191008154729.5b16ef26@bahia.lan> (raw)
In-Reply-To: <2456208.kOTvEbKLdM@silver>

On Tue, 08 Oct 2019 14:05:28 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> On Dienstag, 8. Oktober 2019 11:14:59 CEST Greg Kurz wrote:
> > > No, it is not a feature. It is still a fix. :) I cannot use 9p without
> > > this
> > > fix at all, so it is not some optional "feature" for me.
> > 
> > I understand your need but this is still arguable. The 9p device has
> > a limitation with cross-device setups. The actual bug is to silently
> > cause inode number collisions in the guest. This is partly fixed by the
> > "9p: Treat multiple devices on one export as an error" patch. Thinking
> > again, it would even make sense to move "remap" from "9p: Added virtfs
> > option 'multidevs=remap|forbid|warn'" to its own patch. We could then
> > consider that the bug is fully fixed with "multidevs=forbid|warn".
> > 
> > Then comes the "remap" feature which is expected to lift the limitation
> > with cross-device setups, with a "not yet determined" performance cost
> > and light reviewing of the code.
> 
> Are these patch transfer requests addressed at me to be done?
> 

It would certainly be appreciated :) and if it happens to be done
before 2019-10-29, it can even be shipped with QEMU 4.2.

> > Also, I strongly recommend you try out "virtio-fs" which is
> > going to be soon the production grade way of sharing files
> > between host and guest.
> > 
> > https://www.mail-archive.com/libvir-list@redhat.com/msg182457.html
> 
> Yes I know, I am following the development of virtio-fs already of course. 
> However for me it is far too early to actually use it in a production 
> environment. It e.g. seems to require bleeding edge kernel versions. And the 
> real argument for switching from 9p to virtio-fs would be a significant 
> performance increase. However so far (correct me if I am wrong) I have not 
> seen benchmarks that would show that this was already the case (yet).
> 
> I wonder though whether virtio-fs suffers from the same file ID collisions 
> problem when sharing multiple file systems.
> 

I don't know.

> What is your long-term plan for 9p? Will it be dropped completely after 
> virtio-fs became stable?
> 

No, 9p will survive. The local backend has an advantage despite its various
limitations: it is really easy to use. No extra command needed. I also want
to keep the synth backend around for testing, but I'll gladly drop the
proxy backend which is clearly superseded by virtio-fs.

Cheers,

--
Greg

> Best regards,
> Christian Schoenebeck
> 
> 