From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:43859 "EHLO
        wout2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1727804AbeLESGy (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Wed, 5 Dec 2018 13:06:54 -0500
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
References: <87va4fbmxp.fsf@vostro.rath.org>
        <CAJfpegvQRmm2bbrrcm=bU5eKYgRoaKirtvfid7PG+=k41Oi+2A@mail.gmail.com>
        <87muppbm7c.fsf@vostro.rath.org>
        <CAJfpegsSd4n=h7kw=66nag0HONkZAMFWgYwekEgAtuWzbYP22Q@mail.gmail.com>
        <87h8ftxgds.fsf@vostro.rath.org>
        <CAJfpegvSfGtcTvoCheXTQtJN=Tt2gQYuS5Sxjnmcq4SUiPgWBQ@mail.gmail.com>
Date: Wed, 05 Dec 2018 18:06:48 +0000
In-Reply-To: <CAJfpegvSfGtcTvoCheXTQtJN=Tt2gQYuS5Sxjnmcq4SUiPgWBQ@mail.gmail.com>
        (Miklos Szeredi's message of "Wed, 5 Dec 2018 10:25:53 +0100")
Message-ID: <87zhtj6e6f.fsf@thinkpad.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: <linux-fsdevel.vger.kernel.org>

On Dec 05 2018, Miklos Szeredi <miklos@szeredi.hu> wrote:
> On Tue, Dec 4, 2018 at 8:04 PM Nikolaus Rath <Nikolaus@rath.org> wrote:
>>
>> On Dec 04 2018, Miklos Szeredi <miklos@szeredi.hu> wrote:
>
>> > The GETATTR requests are due atime invalidations.
>>
>> Could you elaborate? I'm not sure what that means here. What is an atime
>> invalidation?
>
> POSIX states that on read(2), readdir(3), readlink(2), etc, the
> st_atime of the file/directory/symlink needs to be updated to the
> current time.  So when e.g. a READ request is sent, fuse will
> invalidate the cache in the belief that the server will update the
> atime.  In this casea subsequent stat(2) will find the invalid cache
> and will issue a GETATTR to the server, which will reply with an
> updated atime value.

This sounds like it should not happen when writeback is active, because
in that case userspace doesn't know the right attributes either.

Or is there special code that only prevents invalidation if there
already is dirty data for the inode? If so, is there a reason for not
updating atime in the kernel whenever writeback is active?

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