On 12.03.25 09:34, Brendan Jackman wrote:
On Tue, Mar 11, 2025 at 08:53:02PM +0100, David Hildenbrand wrote:
2. 9pfs seems to pass the f_type through from the host. So you can't
detect it this way anyway.
[3. I guess overlayfs & friends would also be an issue here although
that doesn't affect my usecase.]
Anyway, I think we would have to scrape /proc/mounts to do this :(
The question I am asking myself: is this a 9pfs design bug or is it a 9pfs
hypervisor bug. Because we shouldn't try too hard to work around hypervisor
bugs.
Which 9pfs implementation are you using in the hypervisor?
I'm using QEMU via virtme-ng. IIUC virtme-ng knows how to use viortfs
for the rootfs, but for individually-mounted directories with
--rwdir/--rodir it uses 9pfs unconditionally.
Ah okay, that makes sense.
Even if it's a bug in QEMU, I think it is worth working around this
one way or another. QEMU by far the most practical way to run these
tests, and virtme-ng is probably the most popular/practical way to do
that.
I'm afraid yes. Although allocating temp files form 9pfs is rather ...
weird. :) One would assume that /tmp is usually backed by tmpfs. But
well, a disto can do what it wants.
I think even if we are confident it's just a bunch of broken
code that isn't even in Linux, it's pragmatic to spend a certain
amount of energy on having green tests there.
Yeah, we're trying ...
(Also, this f_type thing might be totally intentional specified
filesystem behaviour, I don't know).
I assume it's broken in various ways to mimic that you are a file system
which you are not.
Your approach is likely the easiest approach to deal with this 9pfs crap.
Can you document in the code+description better what we learned, and why
we cannot even trust f_type with crappy 9pfs?
---
Cheers,
David / dhildenb
