Hi Chuck, On Thu, Dec 8, 2011 at 10:40 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > On Dec 8, 2011, at 2:19 PM, Tom Gundersen wrote: > >> /run is guaranteed to be available and writeable at any time, whereas >> /var might be on a separate partition and hence not available during >> early boot. By moving the socket from /var to /run we are able to use >> rpcbind earlier, which would in particular make a difference in case >> /var is on an nfs mount, something I am currently seeing bug reports >> about. > > I don't understand this part. /var should be mounted with "nolock" so there should not be a need to have rpcbind running. Can you explain what this is about? You are right, this particular problem can be written off as a configuration error. However, if I understand correctly moving /var/run and /var/lock off of /var would eliminate the need to mount /var with nolock, and things would "just work", regardless of the mount options. Another reason to want the sockets in /run would be the desire to start using rpcbind before /var is mounted (even if /var does not itself rely on rpcbind). E.g. to start mounting a remote /home while the local /var is still being fsck'ed. >> This change should not make a difference to software that currently >> works as intended, as /var/run should be a symlink or bindmounted >> to /run, so anyone relying on the socket being in /var/run will >> still find it there. > > Even the kernel? Good question, it had not occurred to me that the kernel might resolve the paths differently than userspace programs. I'll have to look into that. Thanks for the feedback! Tom -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
