On Sunday October 14, lm@bitmover.com wrote:
> Hi, the open(2) man page says:
>
> O_EXCL When used with O_CREAT, if the file already exists
> it is an error and the open will fail. O_EXCL is
> broken on NFS file systems, programs which rely on
> it for performing locking tasks will contain a race
> condition. The solution for performing atomic file
> locking using a lockfile is to create a unique file
> on the same fs (e.g., incorporating hostname and
> pid), use link(2) to make a link to the lockfile.
> If link() returns 0, the lock is successful. Oth
> erwise, use stat(2) on the unique file to check if
> its link count has increased to 2, in which case
> the lock is also successful.
>
> I coded this up and tried it here on a cluster of different operating
> systems (Linux 2.4.5 server, linux, freebsd, solaris, aix, hpux, irix
> clients) and it doesn't work.
>
> 2 questions:
>
> a) is it the belief of folks here that this should work?
No. It is unsupportable with NFSv2.
The NFSv3 protocol does provide support, the I don't think the Linux
NFSv3 client supports it yet because the VFS layer tries to handle all
the exclusion, and doesn't give the file-system a chance.
>
> b) if performance isn't a big issue, is there any portable way to do
> locking over NFS with just files?
Instead of creating a lock file, create a lock symlink.
Have the content of the symlink be something recognisably unique.
e.g. hostname.pid
If the "symlink" syscall succeeds, you have got the lock.
If it fails, issue a readlink and see if the content is what you
tried to create (RPC packet loss and retransmit could have caused
an incorrect failure return). If it is, you have the lock.
If not, you don't.
Similar tricks can be done with hard links if you really want a
file.
i.e. create a file with a unique name and then hard-link it to the
lock-file-name. On apparent failure, check the inode number.
With all these approaches (including O_EXCL) the tricky bit is
cleaning up after a failed application left a lockfile lying
around.
Automatically deleting it is racy unless you guarantee that only
one process could ever consider deleting an old lock file. e.g. a
cron job on the fileserver that runs every 5 minutes and deletes
any lock file older that 10 minutes.
NeilBrown
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 15 2001 - 21:00:55 EST