Linux filesystem development
 help / color / mirror / Atom feed
From: Bernd Schubert <bernd.schubert@fastmail.fm>
To: Han-Wen Nienhuys <hanwenn@gmail.com>
Cc: Joanne Koong <joannelkoong@gmail.com>,
	linux-fsdevel@vger.kernel.org, Miklos Szeredi <miklos@szeredi.hu>
Subject: Re: Interrupt on readdirplus?
Date: Wed, 11 Sep 2024 12:31:10 +0200	[thread overview]
Message-ID: <be572f0c-e992-4f3f-8da0-03e0e2fa3b1e@fastmail.fm> (raw)
In-Reply-To: <CAOw_e7YvF5GVhR1Ozkw18w+kbe6s+Wf8EVCocEbVNh03b23THg@mail.gmail.com>



On 9/11/24 12:07, Han-Wen Nienhuys wrote:
> On Wed, Sep 11, 2024 at 11:51 AM Bernd Schubert
> <bernd.schubert@fastmail.fm> 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

  reply	other threads:[~2024-09-11 10:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-10 12:45 Interrupt on readdirplus? Han-Wen Nienhuys
2024-09-10 15:58 ` Bernd Schubert
2024-09-10 17:38   ` Han-Wen Nienhuys
2024-09-10 19:19     ` Bernd Schubert
2024-09-10 22:03     ` Joanne Koong
2024-09-11  9:47       ` Han-Wen Nienhuys
2024-09-11  9:51         ` Bernd Schubert
2024-09-11 10:07           ` Han-Wen Nienhuys
2024-09-11 10:31             ` Bernd Schubert [this message]
2024-09-11 12:08               ` Han-Wen Nienhuys
2024-09-11 13:06                 ` Bernd Schubert
2024-09-11 15:59                   ` Han-Wen Nienhuys
2024-09-11 16:42                     ` Bernd Schubert
2024-09-12 17:26                   ` Han-Wen Nienhuys
2024-09-12 17:48                     ` Bernd Schubert
2024-09-13 10:36                   ` Han-Wen Nienhuys

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=be572f0c-e992-4f3f-8da0-03e0e2fa3b1e@fastmail.fm \
    --to=bernd.schubert@fastmail.fm \
    --cc=hanwenn@gmail.com \
    --cc=joannelkoong@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox