A filesystem for virtualization [LWN.net]

A filesystem for virtualization

Posted May 15, 2019 9:16 UTC (Wed) by eru (subscriber, #2753)
Parent article: A filesystem for virtualization

A very welcome addition. The 9p file system sucks even worse than noted: it does not support symlinks properly, which at one time caused me hours of wasted time when trying to build a project in a VM that mounted a host directory via 9p (just had to quit trying that, and switched to using docker).

to post comments

A filesystem for virtualization

Posted May 15, 2019 10:19 UTC (Wed) by grawity (subscriber, #80596) [Link] (4 responses)

Symlink support was supposed to be added by 9p2000.L, or does nobody implement that?

A filesystem for virtualization

Posted May 15, 2019 21:23 UTC (Wed) by dezgeg (guest, #92243) [Link] (3 responses)

It is implemented by the Linux kernel as 9p client + QEMU as 9p server combo. Symlinks indeed work correctly.

Offhand I know at least these things are broken in that combo though:
- Creating a file with open(O_CREAT|O_RDWR) but giving a mode that doesn't allow write access fails. This is observable in practice by rsync/cp of files with 0444 mode failing.
- Creating an xattr with zero length value fails, because in the protocol this is interpreted as xattr deletion.

A filesystem for virtualization

Posted May 16, 2019 9:07 UTC (Thu) by eru (subscriber, #2753) [Link]

It is implemented by the Linux kernel as 9p client + QEMU as 9p server combo

Just the combination that did not work for me. Some forms of symlinking did, but not all (I think giving the link target as a relative reference failed, but it was a couple of years ago, so I might remember inaccurately). I did not investigate this further, after figuring out why my build runs failed in an odd way.

A filesystem for virtualization

Posted May 17, 2019 8:30 UTC (Fri) by vdanjean (subscriber, #1552) [Link] (1 responses)

> Creating a file with open(O_CREAT|O_RDWR) but giving a mode that doesn't allow write access fails. This is observable in practice by rsync/cp of files with 0444 mode failing.

This is not specific to 9p. I observed the same problem with a kerberos NFSv4 config. And git is using this pattern... My client runs the latest Linux kernel, but I do not have access to the server (probably a CentOS but I do not know its kernel version). I end up writing a small library to intercept such 'open' calls and changing them in separate system calls. I know I lost atomicity, but I gain a working git in this NFS mount. If needed, the code is here : https://gitlab.inria.fr/NGS/nfs-workaround

A filesystem for virtualization

Posted May 17, 2019 13:38 UTC (Fri) by bfields (subscriber, #19510) [Link]

That's a bug--unfortunately, probably a bug in your server of unknown version. (You can verify who's at fault by running wireshark and seeing exactly where it's failing). NFS has always supported write opens that create read-only files.

(Basically NFS servers allow the owner of a file to override permissions and leave enforcement to the client in these cases. It's a minimal loss of security (since the owner could change the permissions anyway) to get better compatibility with local filesystem behavior.)