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

Augie Fackler raf at durin42.com
Mon Feb 13 17:35:34 EST 2017


> On Feb 13, 2017, at 17:32, Simon Farnsworth <simonfar at fb.com> wrote:
> 
> 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...

All of this makes me wary of a config knob that lets users opt in to corruption. I mean, I've heard horror stories about Subversion users setting "SVN_I_LOVE_CORRUPTED_WORKING_COPIES_SO_DISABLE_SLEEP_FOR_TIMESTAMPS" in their environment, only to get upset when the promised corruption occurred...

> -- 
> Simon Farnsworth



More information about the Mercurial-devel mailing list