Tim Cutts <[EMAIL PROTECTED]> writes: > On 10 Jun 2008, at 9:27 pm, Philippe Troin wrote: > > > This is caused by amd's top-level mounts which are mounted by default > > with NLM locks enabled (lock mount option). Locks are not required > > for the top-level mounts. > > > The attached patch passes "nolock" to > > top-level mount requests. > > It's a more fundamental problem than that, I think, Philippe, isn't > it? Have you seen the discussions on the mailing list?
Where at? I've just seen the bug log. > Your patch might be a useful workaround though, until upstream fix > the problem properly. I do not think so. I think this is the right way to solve the problem. > An alternative workaround is to make using > autofs for the intercepts the default configuration. But that isn't > entirely backward compatible with previous behaviour. Yes. I dislike autofs as it prevents amd from being shut down or upgraded. > Does it actually fix the problem, or just make the error go away? > What happens if you try to lock files on filesystems that have been > automounted? Does that still work? Yes. Let me try to restate the problem: When the kernel mounts an NFS file system, it tries to connect to the NLM service on the remote host (NFS server), unless "nolock" is passed as an option. Until 2.6.25, if the "remote host" was unparseable (for example, [EMAIL PROTECTED]), nolock was assumed. Since 2.6.25, the mount request fails. The patch just passes "nomount" to the kernel for the "toplvl" AMD fs type. That's just the amd-managed NFS mountpoint (for example /net in the stock config). Amd does not provide any locking service for these mount points. They just contain directories or symlinks to the actual NFS mount points. Does that make sense? I'm using this patch in production servers, and NFS locking work fine. Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
