Don't cache sshfs directory, fixes abiosoft/colima#99

[rfay]

• Unreliable sshfs bind mount - directories/files gradually appear after container start abiosoft/colima#99

sshfs caching can cause asynchronous behaviors that aren't very happy, as discussed in https://stackoverflow.com/questions/3671350/any-way-to-eliminate-time-lag-with-sshfs

This adds the cache=no option to sshfs mounts to prevent this issue

In my case, a ddev test was adding a bunch of files to a mounted directory before starting a container that bind-mounted them. On the way up, it tried to access those files inside the container and got interesting behaviors where the files were listable, but not yet readable. SO

file /mnt/ddev_config/.homeadditions/.composer/auth.json
/mnt/ddev_config/.homeadditions/.composer/auth.json: regular file, no read permission

but

cat /mnt/ddev_config/.homeadditions/.composer/auth.json
cat: /mnt/ddev_config/.homeadditions/.composer/auth.json: No such file or directory

and of course a cp -r would fail.

[jandubois]

It is not clear to me that this is the best option. Reading the osxfuse wiki page for this claims that you need to pair -o cache=no with -o nolocalcache, and recommends -o auto_cache instead (which may have better performance while also solving/reducing the caching issue).

So I guess I would like to see some explanation why we would choose one options over the other.

[rfay]

Thanks for the good thinking and link. I tried out the other options, but something was wrong with my testing, so I'll go back to it again and see what I can sort out.

[rfay]

I tried each combination as suggested in docs

• auto_cache does not solve the problem
• cache=no (as in this PR) does solve the problem
• nolocalcaches is not an sshfs option, it's "fuse for osx" option, I'm not sure. I'm not sure where that would be configured, but am certainly interested.

Bottom line is that the PR as it is is the only one that prevents this issue.

[dee-kryvenko]

I am facing the same (or similar) issue running Terraform in a pod with hostPath volume: hashicorp/terraform#30318. This is definitely related to sshfs as I can't reproduce that issue in the container nor the host outside of any sshfs mounts.

I do not remember facing this issue on RD <0.7.0. I wonder if there was any sshfs related changes in 0.7.0 or 0.7.1?

[dee-kryvenko]

I am able to reproduce this with a simple git clone https://github.com/foo/bar.git && (cd bar && git checkout v0.1.4). If I do git clone https://github.com/foo/bar.git && (cd bar && git diff) - it shows random files being deleted:

$ git clone https://github.com/foo/bar.git && (cd bar && echo ">>> First diff" && git status && git diff && sleep 5s && echo ">>> Second diff" && git status && git diff)
Cloning into 'bar'...
remote: Enumerating objects: 271, done.
remote: Counting objects: 100% (271/271), done.
remote: Compressing objects: 100% (133/133), done.
remote: Total 271 (delta 125), reused 251 (delta 114), pack-reused 0
Receiving objects: 100% (271/271), 59.01 KiB | 397.00 KiB/s, done.
Resolving deltas: 100% (125/125), done.
>>> First diff
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   VERSION

no changes added to commit (use "git add" and/or "git commit -a")
diff --git a/VERSION b/VERSION
index 49d5957..e69de29 100644
--- a/VERSION
+++ b/VERSION
@@ -1 +0,0 @@
-0.1
>>> Second diff
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

Each time it's a new set of files.

[jandubois]

Bottom line is that the PR as it is is the only one that prevents this issue.

Thanks! In that case I guess this is the way we have to go, and hope that 9p support will arrive soon. Leaving final decision to merge to @AkihiroSuda

[AkihiroSuda]

This option seems specific to sshfs v2?
https://github.com/libfuse/sshfs/blob/ef3870a99710447a1c9219c6fcfce34bc5ab9760/sshfs.1.in#L67

Doesn't seem supported in sshfs v3 (not documented, at least)
https://github.com/libfuse/sshfs/blob/master/sshfs.rst

[AkihiroSuda]

Ubuntu dpkg has really weird versioning scheme.. not sure whether we are using v3 or v2 🤷‍♂️
https://pkgs.org/download/sshfs
sshfs_3.6.0+repack+really2.10-0ubuntu1_amd64.deb

[AkihiroSuda]

v3 seems to have undocumented support for cache=no, so LGTM

https://github.com/libfuse/sshfs/blob/a2054a2b737577b63e97ea34d8c9976048766719/sshfs.c#L523-L525

[AkihiroSuda]

Thanks