[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