On 11 Jun 2008, at 6:53 am, Philippe Troin wrote:
Where at? I've just seen the bug log.
Let me rummage through my email a second ... see:
http://bugzilla.kernel.org/show_bug.cgi?id=10349
and
https://bugzilla.am-utils.org/show_bug.cgi?id=612
for various discussions. The second one shows two potential
solutions, one to do as you do and add nolock, the other to not abuse
the hostname field by putting the PID in it. Which of these solutions
do you think best? I think I prefer the second one (making the
hostname field correct, rather than abusing it).
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.
My understanding from the kernel bug report is that there's also a
related but separate issue that am-utils is claiming to support
NFS_MOUNT_VERSION == 6, but then does not use the correct struct for
that version. So that's a separate issue that requires fixing. :-)
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.
My experience in production is that the same is often true of the NFS
version as well - if the currently automounted filesystems are still
in use it has a tendency to get very confused. The shutdown takes an
absolute age, and the restarted copy doesn't always work.
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?
Yes.
I'm using this patch in production servers, and NFS locking work fine.
OK, cool, thanks for that - good to know. I'll have a look today and
see what I can do.
Tim
--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
