On Fri, 17 May 2019 10:40:48 +0200 Christian Schoenebeck <qemu_...@crudebyte.com> wrote:
> On Dienstag, 7. Mai 2019 18:16:08 CEST Christian Schoenebeck wrote: > > Here are the archive links for latest v3 patch set [5(+1) patches total]: > > > > [PATCH v3 0/5] 9p: Fix file ID collisions: > > https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01143.html > > > > [PATCH v3 1/5] 9p: mitigates most QID path collisions: > > https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01142.html > > > > [PATCH v3 2/5] 9P: trivial cleanup of QID path collision mitigation: > > https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01140.html > > > > [PATCH v3 3/5] 9p: persistency of QID path beyond reboots / suspensions: > > https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01144.html > > > > [PATCH v3 4/5] 9p: use variable length suffixes for inode mapping: > > https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01141.html > > > > [PATCH v3 5/5] 9p: adds virtfs 'vii' device parameter > > https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01138.html > > > > And the optional libvirt patch: > > > > [libvirt patch] qemu: adds support for virtfs 9p argument 'vii': > > https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01223.html > > > > > > Please just have a glimpse on that v3 thread, and before I address the > > > > details that you requested (I have reviewed them all already and will > > > > address them), I would like you to ask you for a coarse feedback on > > > > design/features first. > > > > > > > Because there are some things where I am unresolved on design level > > > > yet: > > > > > > I'll try but probably not before next week. > > Hi Greg, you have not forgotten about me, did you? ;-) > Hi Christian, I have certainly not forgotten but I had (and still have) some more urgent work to do and I couldn't find time for this... Sorry :) > Or should I go ahead and provide a v4 next week addressing the issues > discussed so far? > Thinking again about the initial issue raised by Antonios, I agree we should at least detect collisions in the existing 9pfs code and emit an error rather than silently returning duplicate QIDs to the client. This would be patch 2 from Antonios's series: only allow a single host device for a given fs device. Then, we come to the bulk problem: how to handle the case where we have multiple devices involved in a directory we want to share ? Antonios's proposal is a clever way to address the collisions, but your work proves it isn't enough... Before going forward, I'd like to consider another approach. What about: 1) de-compose the shared directory on a per-device basis, ie. identify all mount points under the shared directory 2) expose found mount points separately, each with its onw 9p device 3) re-compose the directory tree within the guest using the same topology as the host ie. if you want to share /vm/fs and /vm/fs on device A /vm/fs/shares on device B /vm/fs/tmp on device C you would start QEMU with -fsdev local,path=/vm/fs,id=fsdev0... \ -device virtio-9p,fsdev=fsdev0,mount_tag=tag0 \ -fsdev local,path=/vm/fs,id=fsdev1... \ -device virtio-9p,fsdev=fsdev1,mount_tag=tag1 \ -fsdev local,path=/vm/fs,id=fsdev2... \ -device virtio-9p,fsdev=fsdev2,mount_tag=tag2 and /etc/fstab in the guest: tag0 / 9p nofail,trans=virtio,version=9p2000.L 0 0 tag1 /shares 9p nofail,trans=virtio,version=9p2000.L 0 0 tag2 /tmp 9p nofail,trans=virtio,version=9p2000.L 0 0 This involves some more work for the user but it doesn't require any changes in QEMU. Would this approach solve the issues you've been hitting with Samba ? Cheers, -- Greg
