Date: Mon, 2 Oct 1995 11:11:16 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: hagen@iesd.auc.dk (Jesper Hagen) Cc: freebsd-questions@freebsd.org Subject: NFS AND FILE LOCKING SEMANTICS EXPLAINED Message-ID: <199510021811.LAA22049@phaeton.artisoft.com> In-Reply-To: <199510021525.QAA28546@xiv.iesd.auc.dk> from "Jesper Hagen" at Oct 2, 95 04:25:03 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I have a question about file locking on FreeBSD is implemented. In > Solaris there is a "lockd"-deamon which is consulted and that handles > locking both locally and across nfs mounted volumes. How is network > file locking implemented in FreeBSD? It is not. I have added kernel support for about 90% of the necessary kernel code, and there is an engineer in England who is working on the client and server code in the daemons. If successful, FreeBSD will be the first public source base that supports NFS locking. As it is, many commercial implementations do not support locking either. > We have some problems with some mail programs that try to lock the > mailbox (which is nfs mounted on a FreeBSD machine from a SunOS > machine). NFS mail file mounting is a bad thing if you run mail programs that rewrite the mailbox. This is because there is, in effect, client caching in all cases, since the buffers are hung locally off the local vnode pointing to the NFS alias vnode. Even with working locking, be prepared to have sendmail trash your mail file if you are updatinging the file from the mailer program at the time new mail comes in. I had this problem on a Sun system, and the only workaround is to *not* NFS mount the mailboxes. Perhaps you could use the POP client/server facilities to get around this problem instead? That is typically the correct way to deal with the mail. > I also notice that it is not possible to lock a device. How is this > done? Device range locks would be meaningless, and therefore impossible to support. You should open the device with O_EXCL if you want exclusive use. The semantic override in the locking code in the file system framework is, in fact, incorrectly implemented and does not apply to the specfs or the new devfs. This is because the semantic override is not implemented at the vfs_syscalls layer; instead, the locks are implemented in the file systems (if they are implemented at all) through calls to common routines. In point of fact, the locks should be implemented unconditionally for all open vnodes (the system call should call lf_advlock), and the call down into the FS itself should be for notification and potential veto by the underlying file system. Further, it should occur *AFTER* the local call, since a local veto will be faster than potentially going remote. I believe that the current range lock implementation is based on an incomplete understanding of the Heidemann file system framework layering model. This is on my list of model inconsistensies that must be corrected, but there are other gross architectural inconsistencies and outright errors that are more important to address at this time. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510021811.LAA22049>