In article <[EMAIL PROTECTED]>, Nelson Posse Lago <[EMAIL PROTECTED]> wrote: >Hi, > >Quite some time ago (somewhere around debian 1.1 and 1.2), it was pointed >out (by Miquel Smoorenburg, I think)
Yep. >that while all debian programs >(or all mail related programs?) agree in using dotfile locking, many of >them used the "wrong" function to implement that, since the commonly used >function is not atomic over NFS (meaning locking could fail over NFS on a >busy machine). Yes, using open("file", O_WRONLY|O_EXCL) is not atomic over NFS. >So, I'd like to know the status of that; is this solved in 1.3.1? What Not really. >about 1.2 (I haven't upgraded yet, I'm lazy ;-) . Or, putting it >differently: can I export my mail spool thru NFS and sleep at night if >all systems involved run debian? No, not by default. There is a way around it however; you can install the libnfslock package. It's a preloaded library that intercepts the open() call. If you use O_EXCL, it does an NFS safe file create using a temp file and the link(2) system call. We've been running with that for quite some time, and I haven't seen any mailbox corruption yet even though me and my collegues read mail over NFS every day.. >On the same line, I think the new (2.1.x) kernel-supported NFS server is >supposed to have the hooks necessary to implement a really cool lockd for >linux which would solve this kind of problem and allow for reliable NFS >locking among linux and other Unixes etc. Yes, but only if: 1. all programs use the same locking protocol (i.e. either safe dotfile locking or fnctl() locking or both in the same order 2. The lockd's between different systems actually cooperate. (1) means you need to inspect all programs anyway, and (2) means it usually works in a homogenous environment. Not between different unixes usually... >Quite misteriously, I don't see >mentions to this when people talk about the improvements of the new >kernels, why is that? And is the lockd really being developed? If so, Yes, lockd is indeed part of the new kernel nfsd, and there is client side support in the 2.1.x NFS client code. >should I expect it to be available when the newer kernel "freezes"? The libnfslock solution is good enough for now, and when all programs use the same locking protocol (which is dotlocking, or file based locking according to the Debian policy) you can remove libnfslock from your system. Note that it doesn't buy us much to move to fnctl() based locking with the kernel lockd, since as I said the most difficult part is to get all programs to just do locking in the same (safe) way, whether that is dotlocking or fnctl() locking. Mike. -- Miquel van Smoorenburg | [EMAIL PROTECTED] | Luck is when preparation meets opportunity -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .