From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com ([66.111.4.25]:42969 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726010AbeLGMzN (ORCPT ); Fri, 7 Dec 2018 07:55:13 -0500 From: Nikolaus Rath To: Miklos Szeredi Cc: linux-fsdevel@vger.kernel.org, fuse-devel Subject: Re: [fuse-devel] [fuse] Speeding up readdir() References: <87va46pgqu.fsf@vostro.rath.org> Date: Fri, 07 Dec 2018 12:55:06 +0000 In-Reply-To: (Miklos Szeredi's message of "Fri, 7 Dec 2018 10:21:41 +0100") Message-ID: <878t11ts2d.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 07 2018, Miklos Szeredi wrote: > On Thu, Dec 6, 2018 at 9:01 PM Nikolaus Rath wrote: >> >> Hello, >> >> I am trying to improve the performance of readdir() requests. I have a >> client application that issues a lot of readdir() requests, and a FUSE >> filesystem that makes extensive use of kernel caching for inode entry >> attributes because retrieving the attributes from the backend is >> relatively expensive. >> >> Unfortunately, it seems to me that currently there is no way to avoid >> having to retrieve the attributes from the backend for every entry that >> is returned by readdir - on every call: >> >> If I am using readdirplus, I have to include the full attributes even if >> the kernel already has them cached. >> >> If I disable readdirplus, I can return just the entry name and its inode >> - but I believe because this doesn't result in a lookup count increase >> of the inode, the kernel can't match this with the existing cached data >> for the inode (is that correct?) and I'm getting a separate lookup() >> request for each entry that I've returned. > > Was the entry timed out? If not, then there shouldn't've been a > lookup. I am not 100% sure because of the atime invalidation issue. Apart from that, it definitely was not timed out. Are you saying that I should not be seeing lookup() requests after (non-plus) readdir() if the dentry is already cached? 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