Glibc 2.20 released

Posted Sep 8, 2014 14:51 UTC (Mon) by geertj (guest, #4116)
In reply to: Glibc 2.20 released by jch
Parent article: Glibc 2.20 released

> It only took some 30 years to get usable POSIX locks.

Anybody knows if the per-fd file range locks support NFS?

I remember that the traditional BSD per-fd locks do not always support it and that was a reason to use the broken, per-process locks.

If NFS is indeed supported, then I agree, after 30 years we get usable file locks :)

Glibc 2.20 released

Posted Sep 8, 2014 15:30 UTC (Mon) by josh (subscriber, #17465) [Link] (8 responses)

> Anybody knows if the per-fd file range locks support NFS?

I would tend to phrase that as "if NFS supports the per-fd file range locks".

I've seen some discussion about NFS and the new locks, but no obvious signs of support.

Glibc 2.20 released

Posted Sep 8, 2014 18:31 UTC (Mon) by bfields (subscriber, #19510) [Link]

Write a quick test and find out.

Looks to me like it should just work, though.

Glibc 2.20 released

Posted Sep 8, 2014 19:39 UTC (Mon) by luto (guest, #39314) [Link] (6 responses)

I'm not sure why NFS should care much. As far as an NFS server is concerned, I assume that a lock is held by a client machine, and I don't see why it would make any difference whether that lock is really help by a process on the client machine or an open file description on the client machine.

(Minor nit: these aren't per-fd locks; they're per-open-file-description locks. This makes a big difference if dup or SCM_RIGHTS is used. Or, for that matter, if fork copies a non-CLOEXEC fd.)

Glibc 2.20 released

Posted Sep 9, 2014 9:03 UTC (Tue) by Wol (subscriber, #4433) [Link] (2 responses)

Look at "revisiting how we put together linux systems". There's a nice subthread on there about how Posix locking is horribly broken over NFS.

Nix said it's fine so long as you've got a pure linux setup. Anything else, and you're into a world of hurt where things work locally but not over NFS, or over NFS but not locally, or they appear locked when they aren't, or or or.

And it's easy to prove, from the spec, that such behaviour is "as designed" :-(

Cheers,
Wol

Glibc 2.20 released

Posted Sep 9, 2014 14:16 UTC (Tue) by bfields (subscriber, #19510) [Link] (1 responses)

Nix said it's fine so long as you've got a pure linux setup. Anything else, and you're into a world of hurt where things work locally but not over NFS, or over NFS but not locally, or they appear locked when they aren't, or or or.

That's not quite right, and not what Nix said.

The problem discussed there is the handling of POSIX (fcntl) and BSD (flock) locks. They do not normally interact with each other, except on NFS, where these days the Linux client translates both into the same kind of NFS lock (because that's the only kind NFS has available).

That behavior is identical whether you're using a Linux server or something else.

Glibc 2.20 released

Posted Sep 17, 2014 18:25 UTC (Wed) by nix (subscriber, #2304) [Link]

The irony is that after saying oooh I've never seen a problem, what did I run into with some of my test code, but a problem clearly attributable to flock() and fcntl() locks blocking each other when they shouldn't.

(Still haven't had a problem that's affected real life -- this was just test code -- but still, thanks, Lennart, I'd have spent ages hunting for the cause of *that* one if it hadn't been for our recent discussion! :) )

Glibc 2.20 released

Posted Sep 9, 2014 14:02 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

Well, it's a new kind of lock. You don't want this sort of lock on the client side to turn into the old form of POSIX lock on the server end, or vice versa. So the protocol will need updating. (Since it needs updating to understand that POSIX locks exist at all, why not do both at once! :) )

Glibc 2.20 released

Posted Sep 9, 2014 14:24 UTC (Tue) by bfields (subscriber, #19510) [Link] (1 responses)

Well, it's a new kind of lock. You don't want this sort of lock on the client side to turn into the old form of POSIX lock on the server end, or vice versa.

I don't see a problem.

The POSIX/BSD problem arises because the two types of locks don't normally conflict with each other, but are forced to on NFS because they must be represented as the same type of lock.

But POSIX and the new open file description locks *do* conflict with each other (see a recent copy of the fcntl(2) man page), so it's simple enough to represent both over the same lock protocol.

So the protocol will need updating. (Since it needs updating to understand that POSIX locks exist at all, why not do both at once! :) )

Note that NFS locking is POSIX-like (in particular, it supports byte ranges), so it's BSD locks that would need to be added.

Glibc 2.20 released

Posted Sep 17, 2014 18:26 UTC (Wed) by nix (subscriber, #2304) [Link]

But POSIX and the new open file description locks *do* conflict with each other (see a recent copy of the fcntl(2) man page), so it's simple enough to represent both over the same lock protocol.

True. I don't know what I was thinking. (Of couse, they'll still wrongly conflict with fnctl() locks...)