Open shalottnet opened 3 years ago
Ref: restic/restic#3550.
I don't really use any of the BSDs, it would really be nice to have someone who cares about them work on them. The extra pain of having to find/upgrade/etc a virtual machine to run tests in is enough that I rarely get around to trying FreeBSD.
For example, is that error from reading, writing, or Go trying to set up its event polling logic? I don't immediately see why a commit that claims to go from EINVAL to reporting ready for writes would make our syscall say not ready for for writes, so it sounds like it has to be on the read side. We just do a read syscall, Go is probably making the fd nonblocking behind our back -- but we can't just busyloop on a read, it needs to integrate with the poller, and why is that not already working?
FreeBSD bug report that has some background info: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258056
FWIW This is reasonably easy to add code for, but I just tested FreeBSD 13.1 and am seeing other weird behavior, such as the /dev/fuse FD just hanging after an unmount, instead of the ENODEV it's supposed to give to shut down neatly. And that behavior changes under truss, sometimes working right, sometimes not. Which means I hesitate the complicate the code base, when the end result is still misbehaving -- I don't think I want to add new code just to satisfy FreeBSD until all the tests pass even when run in a loop.
I'm not sure I can continue supporting FreeBSD/OpenBSD without engagement with the FreeBSD/OpenBSD kernel development side, and I frankly don't have time or motivation for that personally. Myself, I will prioritize new Linux features over accommodating the BSDs.
Ways out of this conundrum: a corporate sponsor telling me FreeBSD FUSE is important to them, or someone stepping up to maintain the FreeBSD side and debugging all the weird hangs I can trigger.
@tv42 I'm a FreeBSD kernel developer, and the FUSE maintainer. However, I'm not a Go programmer. If you think you've found other bugs in FreeBSD's FUSE driver, I'll fix them. But could you please try to reproduce them in C first?
Seems that a related problem is at golang: https://github.com/golang/go/issues/54100
Does it helps?
That FreeBSD bug, which actually turned out not to be in fusefs, is now fixed. The fix will be included in the next builds of 14.0-CURRENT.
I note that this library no longer compiles with GOOS=freebsd
# bazil.org/fuse
Error: ../../../../go/pkg/mod/bazil.org/fuse@v0.0.0-20230120002735-62a210ff1fd5/fuse_kernel.go:1011:43: undefined: unix.FALLOC_FL_KEEP_SIZE
Error: ../../../../go/pkg/mod/bazil.org/fuse@v0.0.0-20230120002735-62a210ff1fd5/fuse_kernel.go:1012:43: undefined: unix.FALLOC_FL_PUNCH_HOLE
@asomers Do you have a pointer to the actual bug / fix in 14.0-CURRENT?
@asomers Do you have a pointer to the actual bug / fix in 14.0-CURRENT?
I think you're talking about this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265736 https://cgit.freebsd.org/src/commit/?id=6c049996ec29bad4a913b019a28f211ab84b0d3d
However, that's not the cause of the build failure described by @ncw. That must be something completely different.
The non compiling is a Go problem.
$ git clone git@github.com:bazil/fuse.git
$ cd fuse
$ GOOS=freebsd go build
# bazil.org/fuse
./fuse_kernel.go:1011:43: undefined: unix.FALLOC_FL_KEEP_SIZE
./fuse_kernel.go:1012:43: undefined: unix.FALLOC_FL_PUNCH_HOLE
Its caused by the package golang.org/x/sys/unix
not having the FALLOC_FL_KEEP_SIZE
and FALLOC_FL_PUNCH_HOLE
symbols. I don't know whether these should be there or not though and I'm out of knowledge as far as freebsd goes, but if someone wants to investigate here is the source of x/sys/unix.
A recent change to FreeBSD has broken apps using the bazil.org/fuse lib.
As of the following commit to the FreeBSD FUSE driver:
CURRENT: https://cgit.freebsd.org/src/commit/?id=7b8622fa220b9c08041102f638f848c48e022644 STABLE: https://cgit.freebsd.org/src/commit/?id=7b096a997fad199eddccfb6784e4b85184d9af17
all apps using this lib fail to mount and print a
resource temporarily unavailable
error:All other FUSE-based filesystems that I tested (exfat, (j)mtpfs, sshfs, etc) work just fine after that commit.