nfsd problems with FreeBSD 5.2.1
Chuck Swiger
cswiger at mac.com
Fri Jul 16 13:06:17 PDT 2004
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
More information about the freebsd-current
mailing list