go-fuse
go-fuse copied to clipboard
opcode POLL
How to solve this err
2023/12/06 08:02:53 Unimplemented opcode POLL
Which platform is this?
Here is a minimum reproduction of the issue with seaweedfs, which uses the v2 api of this library.
i'm using ubuntu22.04
This seems caused by mapping a FUSE-mounted non-root non-mount-point directory to a directory in a container. So somehow it did not match the first if
clause.
if req.inHeader.NodeId == pollHackInode ||
req.inHeader.NodeId == FUSE_ROOT_ID && len(req.filenames) > 0 && req.filenames[0] == pollHackName {
doPollHackLookup(ms, req)
} else if req.status.Ok() && req.handler.Func == nil {
log.Printf("Unimplemented opcode %v", operationName(req.inHeader.Opcode))
req.status = ENOSYS
} else if req.status.Ok() {
req.handler.Func(ms, req)
}
Maybe the fix is always return ENOSYS
for any POLL requests for any folder.
Maybe the fix is always return ENOSYS for any POLL requests for any folder.
Won't that ensure that no one can ever run prometheus (and possibly mariadb) on any filesystem mounted with this library? Because that would really be a shame...
I don't see how the crash in https://github.com/seaweedfs/seaweedfs/issues/4241#issuecomment-1863513734 :
unexpected fault address 0x7fe264a21000
fatal error: fault
[signal SIGBUS: bus error code=0x2 addr=0x7fe264a21000 pc=0x4720a2]
and POLL are related.
This looks more like a mmap-related READ is failing. Having a FUSE debug log would help.
@rfjakob This is the output from the weed mount
command with the -debug
flag added:
2023/12/26 21:48:34 rx 18: LOOKUP n1 ["prom"] 5b
2023/12/26 21:48:34 tx 18: OK, {n18366158651401687022 g1 tE=1s tA=1s {M020000040755 SZ=0 L=1 65534:65534 B0*512 i0:18366158651401687022 A 1703645289.000000 M 1703645289.000000 C 1703645289.000000}}
2023/12/26 21:48:34 rx 20: GETXATTR n18366158651401687022 {sz 4096} ["system.posix_acl_access"] 24b
2023/12/26 21:48:34 tx 20: 61=no data available
2023/12/26 21:48:34 rx 22: LOOKUP n18366158651401687022 ["queries.active"] 15b
2023/12/26 21:48:34 tx 22: 2=no such file or directory, {n0 g0 tE=0s tA=0s {M00 SZ=0 L=0 0:0 B0*0 i0:0 A 0.000000 M 0.000000 C 0.000000}}
2023/12/26 21:48:34 rx 24: LOOKUP n18366158651401687022 ["queries.active"] 15b
2023/12/26 21:48:34 tx 24: 2=no such file or directory, {n0 g0 tE=0s tA=0s {M00 SZ=0 L=0 0:0 B0*0 i0:0 A 0.000000 M 0.000000 C 0.000000}}
2023/12/26 21:48:34 rx 26: CREATE n18366158651401687022 {0100644 [RDWR,CREAT,TRUNC,0x8000] (022)} ["queries.active"] 15b
2023/12/26 21:48:34 tx 26: 38=function not implemented, {n0 g0 {M00 SZ=0 L=0 0:0 B0*0 i0:0 A 0.000000 M 0.000000 C 0.000000} &{0 0 0}}
2023/12/26 21:48:34 rx 28: MKNOD n18366158651401687022 {0100644 (022), 0} ["queries.active"] 15b
2023/12/26 21:48:34 tx 28: OK, {n16326915058498505665 g1 tE=1s tA=1s {M0100644 SZ=0 L=1 65534:65534 B0*512 i0:16326915058498505665 A 1703645314.000000 M 1703645314.000000 C 1703645314.000000}}
2023/12/26 21:48:34 rx 30: OPEN n16326915058498505665 {RDWR,0x8000}
2023/12/26 21:48:34 tx 30: OK, {Fh 0 }
2023/12/26 21:48:34 rx 32: POLL n16326915058498505665
2023/12/26 21:48:34 Unimplemented opcode POLL
2023/12/26 21:48:34 tx 32: 38=function not implemented
2023/12/26 21:48:34 rx 34: GETXATTR n16326915058498505665 {sz 0} ["security.capability"] 20b
2023/12/26 21:48:34 tx 34: 61=no data available
2023/12/26 21:48:34 rx 36: SETATTR n16326915058498505665 {size 20001, fh 0}
2023/12/26 21:48:34 tx 36: OK, {tA=1s {M0100644 SZ=20001 L=1 65534:65534 B40*512 i0:16326915058498505665 A 1703645314.000000 M 1703645314.000000 C 1703645314.000000}}
2023/12/26 21:48:34 rx 38: READ n16326915058498505665 {Fh 0 [0 +20480) L 0 RDWR,0x8000}
2023/12/26 21:48:34 tx 38: OK
2023/12/26 21:48:34 rx 40: FLUSH n16326915058498505665 {Fh 0}
2023/12/26 21:48:34 tx 40: OK
2023/12/26 21:48:34 rx 42: RELEASE n16326915058498505665 {Fh 0 RDWR,0x8000 L0}
2023/12/26 21:48:34 tx 42: OK
If there's any more information you need, tell me how to get it and I will happily provide it :)
Won't that ensure that no one can ever run prometheus (and possibly mariadb) on any filesystem mounted with this library? Because that would really be a shame...
due to how the Go runtime works, you have to pick between supporting unittests for filesystems, or supporting POLL. Since unittests more important than POLL, POLL is usually disabled centrally on mount. In this case, your app receives a further POLL opcode, which means that we didn't succeed in disabling POLL. Doesn't you debug log say something like
7:41:34.335181 rx 4: LOOKUP n1 [".go-fuse-epoll-hack"] 20b 17:41:34.335214 tx 4: OK, {n18446744073709551615 g0 tE=0s tA=0s {M0100644 SZ=0 L=1 0:0 B0*0 i0:18446744073709551615 A 0.000000 M 0.000000 C 0.000000}} 17:41:34.335230 rx 6: ACCESS n1 {u=1000 g=1000 r} 17:41:34.335248 tx 6: OK 17:41:34.335266 rx 8: OPEN n18446744073709551615 {LARGEFILE} 17:41:34.335273 tx 8: OK, {Fh 18446744073709551615 } 17:41:34.335350 rx 10: POLL n18446744073709551615 17:41:34.335403 tx 10: 38=function not implemented