Hi Han-Wen,
On 9/10/24 14:45, Han-Wen Nienhuys wrote:
> Hi there,
>
> I have noticed Go-FUSE test failures of late, that seem to originate
> in (changed?) kernel behavior. The problems looks like this:
>
> 12:54:13.385435 rx 20: OPENDIR n1 p330882
> 12:54:13.385514 tx 20: OK, {Fh 1 }
> 12:54:13.385838 rx 22: READDIRPLUS n1 {Fh 1 [0 +4096) L 0 LARGEFILE} p330882
> 12:54:13.385844 rx 23: INTERRUPT n0 {ix 22} p0
> 12:54:13.386114 tx 22: OK, 4000b data "\x02\x00\x00\x00\x00\x00\x00\x00"...
> 12:54:13.386642 rx 24: READDIRPLUS n1 {Fh 1 [1 +4096) L 0 LARGEFILE} p330882
> 12:54:13.386849 tx 24: 95=operation not supported
>
> As you can see, the kernel attempts to interrupt the READDIRPLUS
do you where the interrupt comes from? Is your test interrupting
interrupting readdir?
> operation, but go-fuse ignores the interrupt and returns 25 entries.
> The kernel somehow thinks that only 1 entry was consumed, and issues
> the next READDIRPLUS at offset 1. If go-fuse ignores the faulty offset
> and continues the listing (ie. continuing with entry 25), the test
> passes.
>
> Is this behavior of the kernel expected or a bug?
>
> I am redoing the API for directory listing to support cacheable and
> seekable directories, and in the new version, this looks like a
> directory seek. If the file system does not support seekable
> directories, I must return some kind of error (which is the ENOTSUP
> you can see in the log above).
Is this with or without FOPEN_CACHE_DIR? Would be helpful to know
if FOPEN_CACHE_DIR - fuse kernel code is quite different when this
is set.
>
> I started seeing this after upgrading to Fedora 40. My kernel is
> 6.10.7-200.fc40.x86_64
>
Would be interesting to know your kernel version before? There is
commit cdf6ac2a03d2, which removes a readdir lock. Although the
commit message explains why it is not needed anymore.
Thanks,
Bernd
