LWN: Comments on "A filesystem for virtualization"

A filesystem for virtualization

kmeyer — Fri, 17 May 2019 16:03:57 +0000

I see, thanks.

Taking a step back, I guess I’m not sure how the proposed open mode would be used by userspace NFS/Samba. The article is a bit light on details there.

A filesystem for virtualization

nybble41 — Fri, 17 May 2019 15:42:42 +0000

> Can't any user that can modify a file already set the mtime arbitrarily (under ordinary unix permissions)?

Setting the mtime is a metadata change which forces the the ctime to be updated, so the change would still be noticed. The proposed flag would allow updates to the file's content without any change in mtime *or* ctime.

A filesystem for virtualization

bfields — Fri, 17 May 2019 13:38:14 +0000

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.)

A filesystem for virtualization

vdanjean — Fri, 17 May 2019 08:30:09 +0000

> 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

dgc — Fri, 17 May 2019 02:48:37 +0000

Yes, the FMODE_NOCMTIME flag is used on XFS by both xfs_fsr (online defragmentation) to move data around the filesytem without applications noticing it and by xfsdump for when it is pulling data out of the filesystem during backups.

It was also used by HSM applications that used DMAPI, but the invisible IO had nothing to do with the DMAPI interface. i.e the HSMs used the same mechanism as xfs_fsr to move data in/out of the filesystem (to/from tape) without any user visible file data or metadata modification. So while DMAPI is no longer in use, the filesystem utilities still use this flag for moving data around the filesystem without leaving traces that users and applications may get upset about...

-Dave.

A filesystem for virtualization

kmeyer — Fri, 17 May 2019 00:55:35 +0000

> The worry about such a flag is that changes can be made to a file's contents without anyone noticing, Myklebust said.

Can't any user that can modify a file already set the mtime arbitrarily (under ordinary unix permissions)? (I would expect SELinux or ACLs / MAC policy can restrict this in some way.) I would assume open() with the "suppress mtime/atime change" flag would cause open() to EPERM or EACCES if the user does not have that capability per security policy, making the concern moot?

A filesystem for virtualization

eru — Thu, 16 May 2019 09:07:19 +0000

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

dezgeg — Wed, 15 May 2019 21:23:35 +0000

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

grawity — Wed, 15 May 2019 10:19:20 +0000

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

A filesystem for virtualization

eru — Wed, 15 May 2019 09:16:03 +0000

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).