init warning on stalled lock probe
init: If lock probing stalls for a long time (eg a broken NFS server), display a message to let the user know what's taking so long.
This commit is contained in:
parent
e998e4a29a
commit
1d41ae5d2a
4 changed files with 59 additions and 13 deletions
|
@ -0,0 +1,20 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2020-06-05T14:43:13Z"
|
||||
content="""
|
||||
So your nfs filesystem is making a posix lock operation block for 2 minutes
|
||||
before, I suppose, it makes it fail.
|
||||
|
||||
Since git-annex has to do a posix lock operation, the only way to make it
|
||||
faster would be to fix the nfs filesystem to not do that. Perhaps by disabling
|
||||
posix locking altogether since it's apparently broken.
|
||||
|
||||
But as far as what git-annex can do, I don't see any possible way to speed it up.
|
||||
|
||||
I agree it could make sense to display a message, although that will also
|
||||
be a message the vast majority of users who are not in this situation would
|
||||
see. Maybe it could wait 1-10 seconds (probably 1000 times as long as it
|
||||
will take in most situations) and if the probe is still ongoing, display a
|
||||
message.
|
||||
"""]]
|
|
@ -0,0 +1,16 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 2"""
|
||||
date="2020-06-05T14:54:31Z"
|
||||
content="""
|
||||
Also, it could check if annex.pidlock is already set globally, and skip the
|
||||
probe. Which maybe would work for you?
|
||||
|
||||
I'm going to implement both the delayed message, and checking
|
||||
annex.pidlock.
|
||||
|
||||
(Timing out the probe after some period of time less than 2 minutes would
|
||||
also be a possibility, but then there could be false positives on
|
||||
filesystems that are just legitimately very slow. Doesn't seem a good
|
||||
idea.)
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue