This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
It was <2016-04-12 wto 10:50>, when Florian Weimer wrote: > On 04/12/2016 10:41 AM, Åukasz Stelmach wrote: > >>> Are you trying to automount /var itself, or is /var a directory >>> monitored by the automounter? >> >> I don't exactly understand the alternative. Let me try to describe what >> happens in my system. >> >> I've got a root fs. There is the /var directory. It is empty. There is >> >> LABEL=var /var ext4 defaults,noatime,x-systemd.automount 0 2 >> >> line in my fstab. x-systemd.automount tells systemd to mount autofs >> under /var, start monitoring it for requests and mount the real ext4 >> file-system when a request comes. > > The traditional use of an automounter is that you have a file system > directory, such as /mnt, which contains several remote file systems, > and each one is mounted on demand once you access the path. > > Instead, you seem to be using the automounter to mount just a single > directory. Actually automounters (both nfs based and autofs based) has always been used to mount single directory. To have several directories mounted in /mnt one had to create those directories there and monitor each one of them individually. > May I ask what is the reason for delayed mounting of /var? It's about making the startup process parallel. Setting up autofs is much quicker than mounting a block-device-backed and lets all programmes (except udev) willing to access /var be started. When they are running they block until /var is mounted and let CPU scheduller assign time to other tasks that do not access /var. And actually it makes my system start faster. >>> The pathname is part of the ABI, so we >>> can't really change it for existing architectures. >> >> I am not sure this is actually true. What is a part of ABI (as far as I >> understand it) is _PATH_VARRUN defined in sysdeps/generic/paths.h and >> sysdeps/unix/sysv/linux/paths.h. However, this isn't what nscd >> uses. nscd has its own definitions in nscd/nscd-client.h and nscd/nscd.h >> which apparently are not exported to /usr/include and are not supposed >> to be used outside nscd. That means it should be possible to change the >> the location wher nscd keeps its stuff without breaking ABI. > > nscd is only the tip of the iceberg. Many NSS modules reference paths > under /var (such as /var/db, /var/run, or /var/lib/sss). Indeed, however I am not interested in any other path than /var/run (which is a symlink to /run anyway) and paths in nscd seem to be "self contained" and independent of any other. -- Åukasz Stelmach Samsung R&D Institute Poland Samsung Electronics
Attachment:
signature.asc
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |