Re: nfsd problems with FreeBSD 5.2.1

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