On 9/11/24 12:07, Han-Wen Nienhuys wrote: > On Wed, Sep 11, 2024 at 11:51 AM Bernd Schubert > <bernd.schubert@xxxxxxxxxxx> wrote: >>> 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.) >>> >> >> That is the part I still do not understand - what is the issue if you do >> not ignore the offset? Is it maybe just the test suite that expects >> offset 25? > > Not ignoring the offset means that I have to be prepared to support > some form of directory seeks. > > Directory seeking is notoriously difficult to implement in general, so > few if any users have actually done this. If you don't have to support > directory seeks, a FS can just compile a list of entries on the > OPENDIR call, which the library can then return piecewise. This is not > correct enough to export the FS over NFS, but this works well enough > for almost any other application. > > I can probably kludge up something if I remember what I sent in the > last readdirplus call, but then I would like to be really sure that I > only have to deal with the last READDIRPLUS call (or READDIR as well? > not sure.) having to be redone. > > Besides being annoying to write, the kludge also takes up memory and > time on every call of readdirplus. > Ok, it was a bit hard to extract that information. Basically kernel behavior doesn't match your expectations and causes overhead. As I wrote in the evening, I think the behavior comes from static bool filldir64() (or other filldir functions) in fs.readdir.c. Oh, I just notice I had posted the wrong line, correct one should be here https://elixir.bootlin.com/linux/v6.10.9/source/fs/readdir.c#L350 As you can see, that is fs/readdir.c - not fuse alone. And I guess it is right to stop on a pending signal. For me a but surprising that the first entry is still accepted and only then the signal is checked. One option would be to ignore that signal in userspace before readdir and to reset after that? Thanks, Bernd
