Re: dotfile locking, NFS and lockd
First of all, thanks a lot for the clarification (and for all the work on linux/debian!). On 4 Mar 1998, Miquel van Smoorenburg wrote: In article [EMAIL PROTECTED], Nelson Posse Lago [EMAIL PROTECTED] wrote: 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. [...] 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. [...] 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. Just to see if I got it straight: By reading the material pointed on this list to me at http://www.swb.de/personal/okir/lockd.html , It's my understanding that the real usefulness of the lockd is that one can make shared locks (everyone reads the file simultaneously, as long as everyone agrees not to mess with the file while others are reading it) and posix locks (to lock only a portion of a file, I guess that's important for databases) work over the network, which is not possible now, but which is not important for email. Correct? Thanx again! Nelson [EMAIL PROTECTED] That's Internet! -- E-mail the word unsubscribe to [EMAIL PROTECTED] TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to [EMAIL PROTECTED] .
dotfile locking, NFS and lockd
Hi, Quite some time ago (somewhere around debian 1.1 and 1.2), it was pointed out (by Miquel Smoorenburg, I think) 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). So, I'd like to know the status of that; is this solved in 1.3.1? What 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? 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. 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, should I expect it to be available when the newer kernel freezes? Thanks in Advance, Nelson [EMAIL PROTECTED] That's Internet! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dotfile locking, NFS and lockd
On Wed, 4 Mar 1998, Nelson Posse Lago wrote: 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. 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, should I expect it to be available when the newer kernel freezes? My understanding is that nfs locking is not part of the new nfs server. There is some work being done on a lockd daemon but it seems to be a low priority. See: http://www.swb.de/personal/okir/status.html. -- Jean Pierre -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dotfile locking, NFS and lockd
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] .
