On Mi, 01.11.17 22:15, NeilBrown (ne...@suse.com) wrote: > > Hmm, rpc_pipefs is a virtual API fs, right? If so, it really shouldn't > > be mounted below /var in the first place. Any chance you can work with > > the NFS folks to maybe move it below /run (or /sys or so) where API > > file systems really belong? Otherwise everybody who wants to run /var > > on FNS will run into the same problems sooner or later. > > > > Neil, maybe you could comment on this? Thanks! > > What good timing.. nfs-utils-2.2.1 was just released yesterday. > It contains > > http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=3892174834ea1a4729348f0ecd3078cc1d5458e4 > > If you have a file /etc/nfs.conf which contains > > [general] > pipefs-directory = /run/nfs/rpc-pipefs > > then a generator will create the required .mount unit, and all > tools and daemons will know where to look for the filesystem.
Any chance this can be made the default? Otherwise everybody who wants /var on NFS will first have to reconfigure things. BTW, I quickly glanced over the patch you linked, and one thing I noticed: you enumerate through /etc/mtab in the generator. However, mtab is long obsolete, and should not be used anymore. In fact we nowadays will "taint" systemd if we notice that /etc/mtab is not a symlink to /proc/self/mounts. It's simply unsupported, and new code really should not reference the concept anymore... (oh, and the offical way to refernce mtab is through libc's _PATH_MOUNTED define btw...) Now, one step better than still using /etc/mtab is using /proc/self/mounts, but that's kinda legacy too, the new thing du jour is /proc/self/mountinfo now. But then again, I'd suggest using statfs and comparing the magic. It's so much simpler... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
