From owner-freebsd-questions@FreeBSD.ORG Thu Sep 21 23:14:29 2006 Return-Path: X-Original-To: freebsd-questions@FreeBSD.org Delivered-To: freebsd-questions@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CBF8616A407 for ; Thu, 21 Sep 2006 23:14:29 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [199.26.172.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BCFD43D49 for ; Thu, 21 Sep 2006 23:14:29 +0000 (GMT) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id k8LNDiVe020946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 21 Sep 2006 16:13:44 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id k8LNDiZX020944 for freebsd-questions@FreeBSD.org; Thu, 21 Sep 2006 16:13:44 -0700 (PDT) Received: by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA29712; Thu, 21 Sep 06 16:12:03 PDT Date: Thu, 21 Sep 06 16:12:03 PDT From: perryh@pluto.rain.com (Perry Hutchison) Message-Id: <10609212312.AA29712@pluto.rain.com> To: freebsd-questions@FreeBSD.org In-Reply-To: References: <20060921182252.GA24321@xor.obsecurity.org> Cc: Subject: Re: 6.1 and NFS X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2006 23:14:29 -0000 >> 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.