From: Nikolaus Rath <Nikolaus@rath.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: fuse-devel <fuse-devel@lists.sourceforge.net>,
linux-fsdevel@vger.kernel.org
Subject: Re: [fuse-devel] [fuse] Unexpectedly large number of getattr() and lookup requests
Date: Tue, 04 Dec 2018 19:04:47 +0000 [thread overview]
Message-ID: <87h8ftxgds.fsf@vostro.rath.org> (raw)
In-Reply-To: <CAJfpegsSd4n=h7kw=66nag0HONkZAMFWgYwekEgAtuWzbYP22Q@mail.gmail.com> (Miklos Szeredi's message of "Tue, 4 Dec 2018 10:36:30 +0100")
On Dec 04 2018, Miklos Szeredi <miklos@szeredi.hu> wrote:
> On Sat, Dec 1, 2018 at 11:00 AM Nikolaus Rath <Nikolaus@rath.org> wrote:
>>
>> On Nov 30 2018, Miklos Szeredi <miklos@szeredi.hu> wrote:
>> > On Thu, Nov 29, 2018 at 10:20 PM Nikolaus Rath <Nikolaus@rath.org> wrote:
>> >>
>> >> Hello,
>> >>
>> >> I am seeing an unexpectedly large number of getattr() and lookup()
>> >> requests being sent to userspace fuse. I am setting a very large
>> >> attr_timeout and entry_timeout, so I would have expected that the
>> >> maximum number of getattr() and lookup() requests is capped by the
>> >> number of distinct files in the filesystem plus the number of forget
>> >> requests.
>> >>
>> >> However, actual numbers are much higher. For example, when running tests
>> >> on a filesystem with 2960 directory entries, I am getting scenarios
>> >> with 203447 lookup requests, 12970 getattr requests, and zero forget
>> >> requests.
>> >>
>> >> Did I misunderstand something about how dentry and attribute caching
>> >> works?
>> >
>> > Debug log might be useful.
>>
>> Here you go!
>>
>> https://www.dropbox.com/s/tg4vyshz4g18sub/fuse-debug.log.xz?dl=1
>
> $ grep LOOKUP fuse-debug.log | wc -l
> 20786
> $ grep -A2 LOOKUP fuse-debug.log |grep "No such file or directory" | wc -l
> 20116
>
> Since it's a lowlevel log, we can't see what the negative lookups are
> for, but by returning ENOENT it is guaranteed that the negative lookup
> can't be cached. Calling fuse_reply_entry() instead with a zero
> nodeid the negative entry can also be cached, which probably helps to
> reduce the number of lookups.
Uh, right. I forgot about that. Thanks!
> The GETATTR requests are due atime invalidations.
Could you elaborate? I'm not sure what that means here. What is an atime
invalidation?
Best,
-Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
next prev parent reply other threads:[~2018-12-04 19:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-29 21:20 [fuse] Unexpectedly large number of getattr() and lookup requests Nikolaus Rath
2018-11-30 7:58 ` Miklos Szeredi
2018-12-01 10:00 ` [fuse-devel] " Nikolaus Rath
2018-12-04 9:36 ` Miklos Szeredi
2018-12-04 19:04 ` Nikolaus Rath [this message]
2018-12-05 9:25 ` Miklos Szeredi
2018-12-05 18:06 ` Nikolaus Rath
2018-12-06 9:26 ` Miklos Szeredi
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=87h8ftxgds.fsf@vostro.rath.org \
--to=nikolaus@rath.org \
--cc=fuse-devel@lists.sourceforge.net \
--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;
as well as URLs for NNTP newsgroup(s).