fuse lib is broken on recent FreeBSD

[shalottnet]

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:

% hellofs /mnt/fuse-test
2021/10/16 00:52:10 resource temporarily unavailable

All other FUSE-based filesystems that I tested (exfat, (j)mtpfs, sshfs, etc) work just fine after that commit.

[greatroar]

Ref: restic/restic#3550.

[tv42]

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?

[emaste]

FreeBSD bug report that has some background info: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258056

[tv42]

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.

[asomers]

@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?

[nunotexbsd]

Seems that a related problem is at golang:
golang/go#54100

Does it helps?

[asomers]

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.

[ncw]

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