From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com ([66.111.4.28]:52715 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726109AbeLDTEw (ORCPT ); Tue, 4 Dec 2018 14:04:52 -0500 From: Nikolaus Rath To: Miklos Szeredi Cc: fuse-devel , linux-fsdevel@vger.kernel.org Subject: Re: [fuse-devel] [fuse] Unexpectedly large number of getattr() and lookup requests References: <87va4fbmxp.fsf@vostro.rath.org> <87muppbm7c.fsf@vostro.rath.org> Date: Tue, 04 Dec 2018 19:04:47 +0000 In-Reply-To: (Miklos Szeredi's message of "Tue, 4 Dec 2018 10:36:30 +0100") Message-ID: <87h8ftxgds.fsf@vostro.rath.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Dec 04 2018, Miklos Szeredi wrote: > On Sat, Dec 1, 2018 at 11:00 AM Nikolaus Rath wrote: >> >> On Nov 30 2018, Miklos Szeredi wrote: >> > On Thu, Nov 29, 2018 at 10:20 PM Nikolaus Rath wro= te: >> >> >> >> 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 te= sts >> >> 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=3D1 > > $ 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 --=20 GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F =C2=BBTime flies like an arrow, fruit flies like a Banana.=C2= =AB