[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v4 3/5] 9p: Added virtfs option "remap_inodes"
From: |
Christian Schoenebeck |
Subject: |
Re: [Qemu-devel] [PATCH v4 3/5] 9p: Added virtfs option "remap_inodes" |
Date: |
Sat, 29 Jun 2019 12:20:49 +0200 |
On Freitag, 28. Juni 2019 16:23:08 CEST Greg Kurz wrote:
> > > This feature applies to all backends IIUC. We don't really care for the
> > > synth backend since it generates non-colliding inode numbers by design,
> > > but the proxy backend has the same issue as local. So...
> >
> > Yeah, I was not sure about these, because I did not even know what these
> > two were for exactly. :) [ lazyness disclaimer end]
>
> "proxy" is a backend where all I/O accesses are performed by a separate
> process running the virtfs-proxy-helper command. It runs with root
> privileges, which provides the same level of functionality as "local"
> with security_model=passthrough. It also chroot() into the shared
> folder for extra security. But it is slower since it all requests
> still go through the virtio-9p device in QEMU. This would call
> for a vhost-9p implementation, but it's yet another story.
>
> "synth" is a software pseudo-backend, currently used to test 9pfs
> with QTest (see tests/virtio-9p-test.c).
Thanks for the clarification!
So the proxy backend sounds like an idea that has not been implemented fully
to its end. I guess it is not really used in production environments, right?
What is the actual motivation for this proxy backend?
And now that I look at it, I am a bit surprised that there is this pure Unix
pipe socket based proxy variant, but no TCPIP network socket variant. I mean
the latter is AFAIK the original idea behind the 9p protocol and IMO might be
interesting to physical separate pure storage backends that way.
Best regards,
Christian Schoenebeck
[Qemu-devel] [PATCH v4 4/5] 9p: stat_to_qid: implement slow path, Christian Schoenebeck, 2019/06/26