On Wed, Sep 11, 2024 at 12:04 AM Joanne Koong <joannelkoong@xxxxxxxxx> wrote: > > A bit of browsing through the Go source code suggests that SIGURG is > > used to preempt long-running goroutines, so it could be issued more or > > less at random. > > > > Nevertheless, FUSE should also not be reissuing the reads, even if > > there were interrupts, right? > > Is there a link to the test? Is it easy to repro this issue? I made an easy repro available over here: https://review.gerrithub.io/c/hanwen/go-fuse/+/1200990 To repro, git init git fetch https://review.gerrithub.io/hanwen/go-fuse refs/changes/90/1200990/1 && git checkout FETCH_HEAD go test ./fs -run TestInterruptReaddirplus -count 2000 to get debug logs, add -v to the test command. Typical output: $ go test ./fs -run TestInterruptReaddirplus -count 2000 11:42:29.186131 writer: Write/Writev failed, err: 2=no such file or directory. opcode: RELEASEDIR 11:42:30.160136 doInterrupt 11:42:30.160559 observed seek --- FAIL: TestInterruptReaddirplus (0.01s) mem_test.go:301: read back 76 entries, want 100 I am using $ uname -a Linux fedora 6.10.7-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Aug 30 00:08:59 UTC 2024 x86_64 GNU/Linux $ go version go version go1.22.6 linux/amd64 > If I'm understanding your post correctly, the issue you are seeing is > that if your go-fuse server returns 25 entries to an interrupted > READDIRPLUS request, the kernel's next READDIRPLUS request is at > offset 1 instead of at offset 25? yes. If the offset is ignored (mustSeek = false in fs/bridge.go), it causes test failures, because of a short read on the readdir result there are too few entries. If I don't ignore the offset, I have to implement a workaround on my side which is expensive and clumsy (which is what the `mustSeek` variable controls.) -- Han-Wen Nienhuys - hanwenn@xxxxxxxxx - http://www.xs4all.nl/~hanwen
