Workaround Fuse-T behavior on macOS#530
Conversation
b3d1e47 to
1e2b342
Compare
|
Discovered some test failures still caused by NFS silliness -- debugging now |
|
This looks like a reasonable approach, I'm sure it was not fun to debug. Any objection to squashing the commits down? It looks like developmental commits rather than feature-complete independent changes. Especially if the intermediate commits aren't fully passing the test cases. |
446cb08 to
055b256
Compare
|
Still working on the test cases, since some of them are still failing due to other NFS weirdness. I will keep the PR to one commit once it is ready :) |
|
It looks like unfortunately macOS also has a few more NFS behaviors that need to be addressed (like crawling upwards searching for .app bundles), so this will probably take a while to be more complete. Thank you for pointing me at the tests! |
|
I failed to make macOS pass tests without a reference, so I'm instrumenting tup and recording its exact behavior on Linux so that I can see where macOS deviates. Might take a couple more days to reach 100% conformance. |
055b256 to
ecb7e0b
Compare
|
I found a lot more things that were wrong with Fuse-T mounts on macOS. I instrumented tup to record its exact behavior in a Linux container, then ran the same tests on macOS and studied for deviations. All but five tests now pass on my machine: with four of the failures being just because I didn't install ccache/python/etc, and t5074-tup-dies.sh being for another reason but I'll open another PR about that in a bit. Maybe try to test on a machine that uses macFUSE because probably none of these workarounds should be used in that case. |
e8f4705 to
6a9e29c
Compare
|
Fixed to also ignore |
6a9e29c to
b25e52f
Compare
With Fuse-T, readdir seems to also stat every directory entry, causing tup to assume false input dependencies; potentially due to Fuse-T's usage of NFS. Due to this, while bootstrapping succeeds, Fuse-T
build/tupwill report errors like this on my machine:(full transcript)
With this PR, on macOS when Fuse-T is likely in use, we now test at startup for this behavior by listing a virtual directory and watching for stat of a virtual sentinel file. We always ensure the behavior at runtime before enabling the workaround, because there could be forks of Fuse-T that fix it or other implementations that never had it (such as macFUSE). The virtual directory itself deactivates after being listed once. Then, if we observe a stat on the sentinel, we assume it was performed automatically as a consequence of the readdir, and enable the workaround. We then stat a virtual "done" file to conclude the probe, deactivating both virtual files to prevent the workaround from being enabled when the behavior is not present. Thus the workaround is only enabled when a stat reaches the sentinel following the readdir but before our stat to the done file.
When the workaround is enabled, readdir will record each result into a cache that tells getattr to ignore one next stat. By ignoring the spurious call to getattr, we avoid assuming a corresponding spurious access, because in this case, the first stat for a child following its parent directory's listing is from the filesystem layer itself, not the running task.
This is my first contribution, so let me know if I'll need to sign a CLA.