Date: Thu, 21 Sep 06 16:12:03 PDT From: perryh@pluto.rain.com (Perry Hutchison) To: freebsd-questions@FreeBSD.org Subject: Re: 6.1 and NFS Message-ID: <10609212312.AA29712@pluto.rain.com> In-Reply-To: <BE6EA75A-48E3-4B4C-B6D0-FF7D728F2ECD@mac.com> References: <C87B42D9-AF83-4DFC-9E13-53FCD874A444@obmail.net> <20060921182252.GA24321@xor.obsecurity.org> <FC0253C7-B04C-4609-96D0-BD8AACAB5646@obmail.net> <BE6EA75A-48E3-4B4C-B6D0-FF7D728F2ECD@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> rpc.lockd remains unreliable; avoid using it if practical. statd and lockd have been problematic ever since Sun invented them a couple of decades ago, at least partly because what they are trying to do is fundamentally not computable. (There is no way to distinguish between the other side having crashed, and a temporary network communication problem that has not yet been resolved but will be eventually. At best, you find out about the other side's crash after it has rebooted, which could be hours or days later if the crash was caused by a hardware failure.) The best solution is to avoid locking files over NFS. For example: * As pointed out in Mark Crispin's article, use IMAP (or POP) instead of having the mailserver export the spool directory. * ssh to the server to do things like adduser, rather than trying to run it on the client. File locking works reasonably well within a single "system" (defined as a combination of hardware and software that all crashes together :) I doubt anyone will ever get it to work all that well when the locks must be shared across a larger entity.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?10609212312.AA29712>