darwin: use simpleHandleMap that never reuses handle numbers #205
Conversation
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 osxfuse/osxfuse#482
| t.Log("expected recovery from: ", r) | ||
| } else { | ||
| panic(s) | ||
| } |
There was a problem hiding this comment.
The markSeen function was not used anywhere
|
I have one concern with this, which is that the other FUSE library (rsc's library and bazil.org which was derived from it.) uses the same approach here. Can you confirm that they too see the vnode changed messages? |
|
I'll try to find out. Even with simpleHandleMap I see (different) osxfuse messages (something about disappearing nodes), but I don't see how we can code this even more defensively to keep osxfuse happy |
|
I could not reproduce the problem the bazil-based keybase/loopback. Still getting lots of but no "vnode changed generation" and no errors returned to user-space. Also, I have a user report that simpleHandleMap makes the problem appear less often but does not fix it, so this seems to be a dead end. |
|
Plot twist: I had the user re-test the change, and it does fix the problem for him:
This matches what I see on the Mac box I managed to get my hands on. While it is curious why it does not happen for bazil, MacOS kernel module development seems to be a world of pain - I gave up when I had to edit an sqlite file in recovery mode to get my self-compiled osxfuse.kext to load. I suggest to merge this workaround that fixes the problem with no obvious downsides. |
|
see Line 85 in da8b3e4 we get the generation number from the handleMap, and we increase it when we hand out a new node, but the effect is persisted, ie. in the sequence lookup -> new node A, gen = 1 A will change generation numbers. Rather than papering the problem over without us understanding what is going on, can we fix the real bug here? |
|
Oh, now I see it. I'll prepare a patch. |
|
And bazil does not have this bug because it returns the saved generation number: if id, ok := c.nodeRef[node]; ok {
sn := c.node[id]
sn.refs++
return id, sn.generation
} |
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
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
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
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. Add test for handle map
behavior.
Fixes #204
See also #205
Implement simpleHandleMap that never reuses handle numbers and
uses a simple map to track handle numbers.
This seems to get rid of the
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
#204
osxfuse/osxfuse#482