[PATCH 2 of 2] lock: include Linux pid namespace identifier in prefix

Simon Farnsworth simonfar at fb.com
Mon Feb 13 17:32:07 EST 2017


On 13/02/2017 19:55, Augie Fackler wrote:
> On Fri, Feb 10, 2017 at 04:50:55PM -0800, Jun Wu wrote:
<snip>
>>
>> I think if we do know the repo is not on NFS, and the system supports
>> flock(), flock() is way more robust and solves all kinds of pain here.
>>
>> I hereby propose a new repo requirement "flock", once set, use flock instead
>> of the traditional lock file. It's off by default. Thoughts?
>
> I'm...not categorically opposed to it, though it feels pretty risky. I
> know git doesn't use flock() either - presumably there's a good reason
> I don't know about that neither tool relies on it?
>

The usual reason is the complete clusterfsck that's flock() on NFS, 
combined with the corporate love of NFS homedirs.

Basically, every significant OS (Linux, macOS, FreeBSD) supports a mode 
where flock() works, but is only respected on the local host (the server 
is never told about the lock). This is a recipe for silent corruption in 
places that use NFSv2 or v3, since there's no way to tell whether locks 
are handled server-side by every client, or if one or more clients are 
handling locks locally and not telling the server about it.

For bonus "excitement", if users have any degree of admin control of 
their own system, they can get a slight performance boost by switching 
locking to local-only (as there's no longer one RTT delay for each 
flock() call). At least, until they forget they did that, and use a 
second host for a concurrent operation...
-- 
Simon Farnsworth


More information about the Mercurial-devel mailing list