From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 20:06:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50BFF16A4CE for ; Fri, 16 Jul 2004 20:06:17 +0000 (GMT) Received: from out003.verizon.net (out003pub.verizon.net [206.46.170.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id D261F43D2F for ; Fri, 16 Jul 2004 20:06:16 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from [192.168.1.3] ([68.161.84.3]) by out003.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040716200616.WAZA6671.out003.verizon.net@[192.168.1.3]>; Fri, 16 Jul 2004 15:06:16 -0500 Message-ID: <40F8350E.70106@mac.com> Date: Fri, 16 Jul 2004 16:05:34 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Thomas References: <40F8157D.5040104@cems.umn.edu> In-Reply-To: <40F8157D.5040104@cems.umn.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out003.verizon.net from [68.161.84.3] at Fri, 16 Jul 2004 15:06:15 -0500 cc: freebsd-current@freebsd.org Subject: Re: nfsd problems with FreeBSD 5.2.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2004 20:06:17 -0000 Mike Thomas wrote: [ ... ] > The machine functions as a nis client for accounts with home directories > nfs mounted from a Solaris 9 machine. It's primary function is as a mail > server, and what it is nfs sharing out is the spool folder. (/var/mail, > in this case). Setting up a FreeBSD system to act as an NFS server to Solaris clients sounds backwards to me. If there is any one specific task that Solaris stands out for, it's probably filesharing. I'm not a fan of Solaris for Intel hardware, but this might be one of the few cases where it would be the better choice. [ ... ] > I have recompiled every single ounce of software that operates on > /var/mail to only use fcntl locking (procmail/postfix/uw-imap (there's a > patch by redhat to do that)) so that it is nfs friendly. Ooh! Are you sure about that? I don't trust rpc.lockd very far on any platform, and the FreeBSD manpage for fcntl makes interesting reading: This interface follows the completely stupid semantics of System V and IEEE Std 1003.1-1988 (``POSIX.1'') that require that all locks associated with a file for a given process are removed when any file descriptor for that file is closed by that process. This semantic means that applica- tions must be aware of any files that a subroutine library may access. For example if an application for updating the password file locks the password file database while making the update, and then calls getpwnam(3) to retrieve a record, the lock will be lost because getpwnam(3) opens, reads, and closes the password database. The database close will release all locks that the process has associated with the database, even if the library routine never requested a lock on the data- base. Another minor semantic problem with this interface is that locks are not inherited by a child process created using the fork(2) function. The flock(2) interface has much more rational last close semantics and allows locks to be inherited by child processes. Flock(2) is recommended for applications that want to ensure the integrity of their locks when using library routines or wish to pass locks to their children. Programs which depend upon filesystem locks tend to say "don't use me over NFS" resulting from hard-learned experience. Explicit file-based locks ("create foo.lock containing the PID of the locking process") do much better over NFS. I also saw a comment that you are using mbox-style mailboxes which may be larger than half a gigabyte in size. Expect this to hurt until you do something else. Using maildir rather than mbox-style mailboxes would probably improve the situation dramaticly. -- -Chuck