From owner-freebsd-net@FreeBSD.ORG Mon Apr 4 19:26:46 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FFD0106566B for ; Mon, 4 Apr 2011 19:26:46 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout027.mac.com (asmtpout027.mac.com [17.148.16.102]) by mx1.freebsd.org (Postfix) with ESMTP id E831D8FC0A for ; Mon, 4 Apr 2011 19:26:45 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp027.mac.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTPSA id <0LJ500HKT7CK9R60@asmtp027.mac.com> for freebsd-net@freebsd.org; Mon, 04 Apr 2011 12:26:45 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-04-04_05:2011-04-04, 2011-04-04, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1104040102 From: Chuck Swiger In-reply-to: Date: Mon, 04 Apr 2011 12:26:44 -0700 Message-id: References: <0F56F33B-C492-4723-B7EC-713AD64E856C@mac.com> To: "Marc G. Fournier" X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: 7-STABLE NFS: fatal: "select lock: Permission denied" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 19:26:46 -0000 On Apr 4, 2011, at 12:14 PM, Marc G. Fournier wrote: >> OK-- Cyrus IMAP uses a variant of maildir, so you're relatively safe even if locking is not available. > > So, just to get this clear ... > > If I were to boot a diskless station using an NFS backend, then that instance would be prone to corruption since lockd wouldn't work, even though the only processes handling the files on that mount? If you're running a diskless system using NFS filesystem for storage, and you run stuff that wants to do fcntl/lockf/flock locking, and rpc.lockd isn't available, then yes, there is risk of data corruption. However, Postfix can use .dotfile locking, even if fcntl (etc) locking is broken, and maildir is designed to avoid needing locking the way mbox does: http://www.postfix.org/NFS_README.html > And this may be where I'm mis-understanding things: > > Does rpc.lockd work at the process level or file system? For instance, in my test case, I'm trying to operate within a jail ... does the rpc.lockd runnig at the primary OS level handle communications between client<->server, irrelevent of whether the process is running in a jail or not? rpc.lockd provides locking at the filesystem level. Locks are performed against file descriptors either for entire files or record-level locking; they are not specific to a single process (indeed, locking would be mostly useless if it was only visible within a single process). Regards, -- -Chuck