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
>
>
next prev parent reply other threads:[~2019-10-08 13:49 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-05 10:42 [Qemu-devel] [PATCH v7 0/3] 9p: Fix file ID collisions Christian Schoenebeck via Qemu-devel
2019-09-04 21:34 ` [Qemu-devel] [PATCH v7 1/3] 9p: Added virtfs option 'multidevs=remap|forbid|warn' Christian Schoenebeck via Qemu-devel
2019-09-04 22:05 ` [Qemu-devel] [PATCH v7 2/3] 9p: stat_to_qid: implement slow path Christian Schoenebeck via Qemu-devel
2019-09-04 22:53 ` [Qemu-devel] [PATCH v7 3/3] 9p: Use variable length suffixes for inode remapping Christian Schoenebeck via Qemu-devel
2019-09-13 17:01 ` [Qemu-devel] [PATCH v7 0/3] 9p: Fix file ID collisions Greg Kurz
2019-09-23 9:50 ` Christian Schoenebeck via
2019-09-23 12:56 ` Greg Kurz
2019-09-23 14:06 ` Christian Schoenebeck via
2019-09-23 14:46 ` Greg Kurz
2019-09-23 15:03 ` Christian Schoenebeck via
2019-09-23 16:50 ` Greg Kurz
2019-09-24 9:31 ` Christian Schoenebeck via
2019-10-08 9:14 ` Greg Kurz
2019-10-08 12:05 ` Christian Schoenebeck
2019-10-08 13:47 ` Greg Kurz [this message]
2019-10-08 14:25 ` Christian Schoenebeck
2019-10-08 14:45 ` Greg Kurz
2019-10-15 9:20 ` Greg Kurz
2019-10-16 9:42 ` virtio-fs: Fix file ID collisions (was: 9p: Fix file ID collisions) Christian Schoenebeck
2019-10-16 13:44 ` Dr. David Alan Gilbert
2019-10-18 13:15 ` Christian Schoenebeck
2019-10-16 14:00 ` Greg Kurz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191008154729.5b16ef26@bahia.lan \
--to=groug@kaod.org \
--cc=antonios.motakis@huawei.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu_oss@crudebyte.com \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.