Date: Fri, 29 Aug 2014 19:54:37 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re: lockf(1) and NFS Message-ID: <1912666252.30566061.1409356477461.JavaMail.root@uoguelph.ca> In-Reply-To: <ltptp4$aaq$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Ivan Voras wrote:
> Hi,
>
> I had some fun troubleshooting NFS locking and among other things,
> found
> that lockf(1) doesn't really work on NFSv4 mounts. Googling around
> (so
> correct me if I'm wrong), it looks like this is because NFS quietly
> translates the old-style locks into POSIX range locks, and those
> cannot
> be acquired exclusively if the file is opened read-only.
>
Yes, the NFSv4 protocol only supports POSIX byte range locks.
The only alternative to translating flock(2) locks to POSIX locks is
to not support flock(2) locks at all.
To be honest, NFSv4 does have Windows style Open locks, which would
implement something close to O_EXLOCK, but not flock(2). Since they
couldn't be flock(2) compatible, I didn't do this.
> I've tested the following patch and it works.
> Any objections to committing it?
>
What happens if the file "name" exists and the process only has read
access to it for a file on a local fs?
(I'm wondering if the patch breaks that case and causes a POLA?)
Alternately you could add a new command option for this case and
document the need to use it for NFSv4 mounts, maybe?
Have fun with it, rick
> --- a/lockf.c Fri Aug 29 14:58:10 2014 +0200
> +++ b/lockf.c Fri Aug 29 14:59:12 2014 +0200
> @@ -169,7 +169,7 @@
> {
> int fd;
>
> - if ((fd = open(name, flags|O_RDONLY|O_EXLOCK|flags, 0666)) == -1) {
> + if ((fd = open(name, flags|O_RDWR|O_EXLOCK|flags, 0666)) == -1) {
> if (errno == EAGAIN || errno == EINTR)
> return (-1);
> err(EX_CANTCREAT, "cannot open %s", name);
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1912666252.30566061.1409356477461.JavaMail.root>