Date: Sun, 27 Jul 2025 22:44:20 +0000 From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 288444] p9fs chokes on mountpoints in the exported filesystem Message-ID: <bug-288444-27103-hqmtFjW9we@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-288444-27103@https.bugs.freebsd.org/bugzilla/> References: <bug-288444-27103@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D288444 Mark Johnston <markj@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open --- Comment #1 from Mark Johnston <markj@FreeBSD.org> --- This is basically a limitation of the 9p protocol as implemented by bhyve (= and QEMU). Each file in a 9p share has a unique 64-bit identifier, the QID, and our lib9p just sets qid =3D st_ino. Of course, inode numbers are not unique across datasets, so aliases arise, and this violates some invariants of p9f= s. It looks like QEMU has an option which lets one work around this problem by dynamically remapping host inode numbers to provide unique QIDs, at the cos= t of some overhead and the lack of a guarantee that it always work. (This is "multidevs=3Dremap".) For 15.0 it seems best to simply disallow exporting anything under a mountpoint. That is, if a walk or readdir encounters a file belonging to a different host mountpoint, the 9p server should either hide it or generate = an error. That's a bit inconvenient, but it's a bit easier to implement and i= t's the safest option. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-288444-27103-hqmtFjW9we>