Messages in this thread | | | Date | Thu, 11 Apr 2024 11:29:07 +0200 | From | Oleg Nesterov <> | Subject | Re: [GIT PULL] fs/9p patches for 6.9 merge window |
| |
On 04/10, Eric Van Hensbergen wrote: > > April 10, 2024 at 12:20 PM, "Eric Van Hensbergen" <eric.vanhensbergen@linux.dev> wrote: > > April 8, 2024 at 9:14 AM, "Oleg Nesterov" <oleg@redhat.com> wrote: > > > Hello, > > > the commit 724a08450f74 ("fs/9p: simplify iget to remove unnecessary paths") > > > from this PR breaks my setup. > >
> I think > I've reproduced the problem, fundamentally, since you have two mount > points you are exporting together. I believe we are getting an inode > number collision which was being hidden by the "always create a new inode > on lookup" inefficiency in v9fs_vfs_lookup. You could probably verify > that for me by stating the /home directory and the / directory on the > server side of your setup.
Yes, yes,
$ ls -ldi / /home 2 dr-xr-xr-x. 18 root root 4096 Jan 4 2016 / 2 drwxr-xr-x. 7 root root 4096 Dec 20 2022 /home
that is why I showed you the relevant parts of my /etc/fstab
> If qemu detects that this is a possibility it usually > prints something: qemu-system-aarch64: warning: 9p: Multiple devices > detected in same VirtFS export,
My qemu is quite old, it doesn't. But I tested this on another machine and yes, the newer qemu does warn.
(annoyingly, I had to redirect stderr to the file to see this warning, it is cleared by the booting kernel otherwise).
> I can confirm that multidevs=remap in qemu does appear to avoid the > problem,
Confirm!
I didn't know about this option (and again, my old qemu doesn't support it), but everything seems to work just fine with the newer qemu and multidevs=remap. Thanks!
So I think this regression is minor.
> now that i can > reproduce the problem, I'm fairly certain I can get a patch together > this week to test to see if it solves the regressions.
Thanks ;)
Oleg.
| |