MacOS breakage: "osxfuse: vnode changed generation" #204
Comments
|
the generation numbes are generated in a harebrained way, Line 85 in da8b3e4 it might be that osxfuse wants some more constraints on the generation number. |
|
Let's see if the osxfuse people can shed some light on this: macfuse/macfuse#482 |
|
Looks very much the same for encfs? https://github.com/vgough/encfs/blob/1c273ecba57d95c529f21d72c7615e2bb8a911cf/encfs/Context.cpp#L190 |
rfjakob
added a commit
to rfjakob/go-fuse
that referenced
this issue
Mar 13, 2018
Implement simpleHandleMap that never reuses handle numbers and uses a simple map to track handle numbers. This hopefully works around the osxfuse: vnode changed generation errors we are seeing on darwin, while sacrificing performance. rfjakob/gocryptfs#213 hanwen#204 macfuse/macfuse#482
rfjakob
added a commit
to rfjakob/go-fuse
that referenced
this issue
Mar 13, 2018
Implement simpleHandleMap that never reuses handle numbers and uses a simple map to track handle numbers. This seems to get rid of the osxfuse: vnode changed generation errors we are seeing on darwin, while sacrificing some performance. I have tested simpleHandleMap on darwin and linux, seems to work fine. rfjakob/gocryptfs#213 hanwen#204 macfuse/macfuse#482
rfjakob
added a commit
to rfjakob/go-fuse
that referenced
this issue
Mar 16, 2018
We used to hand out a new generation number even for already-known handles. This does not seem to cause problems on Linux, but osxfuse throws errors to userspace with osxfuse: vnode changed generation showing up in the kernel log. Introduce a per-handle generation number that stays constant until the handle is forgotten. Fixes hanwen#204 See also hanwen#205
rfjakob
added a commit
to rfjakob/go-fuse
that referenced
this issue
Mar 16, 2018
We used to hand out a new generation number even for already-known handles. This does not seem to cause problems on Linux, but osxfuse throws errors to userspace with osxfuse: vnode changed generation showing up in the kernel log. Introduce a per-handle generation number that stays constant until the handle is forgotten. Tested on Linux and MacOS via gocryptfs. Fixes hanwen#204 See also hanwen#205
rfjakob
added a commit
to rfjakob/go-fuse
that referenced
this issue
Mar 16, 2018
We used to hand out a new generation number even for already-known handles. This does not seem to cause problems on Linux, but osxfuse throws errors to userspace with osxfuse: vnode changed generation showing up in the kernel log. Introduce a per-handle generation number that stays constant until the handle is forgotten. Tested on Linux and MacOS via gocryptfs. Fixes hanwen#204 See also hanwen#205
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I recenty got a ticket filed against gocryptfs with macos users seeing errors when copying files: rfjakob/gocryptfs#213
I have now managed to get my hands on macos box (high sierra, osxfuse 3.7.1). The extractloop.bash stress test reproduces the issue, both for gocryptfs (just run
./extractloop.bash) and loopback (running./extractloop.bash -loopback).The tar extract fails with lots of
errors while we get these osxfuse errors in dmesg:
I was tempted to suggest that osxfuse is just completely broken, but
./extractloop.bash -encfs(running the same tarball extract test against encfs) works fine. So I guess we should be doing something differently on macos. Ideas?The text was updated successfully, but these errors were encountered: