Messages in this thread | | | Date | Sat, 28 Dec 1996 10:25:29 -0800 (PST) | From | Christoph Lameter <> | Subject | NFS Problem in Kernel 2.0.27: inode status not updated |
| |
There is a new mailer available for Linux called exim. It sports some locking scheme that claims to work better under NFS. But it does not work under Linux.
It first opens a lockfile with a unique name and then links that one to the classic /var/spool/mail/username.lock lockfile. Then it checks the number of links on that file. If there are two then the lock is successful. Problem is Linux fstat call always returns 1 for the number of links even though a link() was done immediately prior.
I wonder if some kind of caching in the NFS client part of the kernel does not properly update the inode information in this situation?
Here is the relevant part of the code that does the locking:
if (ob->use_lockfile) { lock_fail_type = "lock file"; hd = open(hitchname, O_WRONLY | O_CREAT | O_EXCL, ob->lockfile_mode); if (hd < 0 && (errno != EACCES || ob->require_lockfile)) { addr->errno = errno; addr->message = "creating lock file hitching post"; return; }
/* If a hitching post exists, attempt to hitch it to the lock file; get its subsequent state, and then get rid of its name. If the hitch was not successful, try again, having unlinked the lock file if it is too old. */
if (hd > 0) { link(hitchname, lockname); fstat(hd, &statbuf); close(hd); unlink(hitchname); if (statbuf.st_nlink != 2) { if (ob->lockfile_timeout > 0 && stat(lockname, &statbuf) == 0 && now - statbuf.st_ctime > ob->lockfile_timeout) { DEBUG(2) debug_printf("unlinking timed-out lock file\n"); unlink(lockname); } continue; } } }
--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- PGP Public Key = FB 9B 31 21 04 1E 3A 33 C7 62 2F C0 CD 81 CA B5
| |