From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 62568C282C4 for ; Mon, 4 Feb 2019 07:50:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2FA8720821 for ; Mon, 4 Feb 2019 07:50:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=szeredi.hu header.i=@szeredi.hu header.b="CZqWBCr5" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726114AbfBDHuV (ORCPT ); Mon, 4 Feb 2019 02:50:21 -0500 Received: from mail-it1-f176.google.com ([209.85.166.176]:32907 "EHLO mail-it1-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725873AbfBDHuV (ORCPT ); Mon, 4 Feb 2019 02:50:21 -0500 Received: by mail-it1-f176.google.com with SMTP id m8so10551687itk.0 for ; Sun, 03 Feb 2019 23:50:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0b5Xf+5EVvLIlJlyrkvygJvDpyaVrODonP19VlLR30o=; b=CZqWBCr5FADGcQQuYiIANruUo6hJMhEgy2EoSIDAC40GkJj0dseZOty6iVoQU9/ccM zyNuzrJST4+KoU5638q01tzZVGPjmQZ17VBxIt8bdC45N4r6p2Hgyf0eQC+f07Fs/sLn UeK+1ZemhCv6fdEVI8qh26FeeztGCn4RyZ43k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0b5Xf+5EVvLIlJlyrkvygJvDpyaVrODonP19VlLR30o=; b=NhcsElP3JhGyiK1o21V7gEmWc8fHozeUnqNXrXIYbDg8HMSH7Y8Mua69KIgtUTkxyA KY3jyvLqkaXSj3adwapDJf900BAkIKnDY268+D1ZkztF4kksawo0rV4hMCHQx4ZZkoKX YhxQfG7PC7wluZOp5jbbOaqiK79aQtJReLKuUaUzu8fTwEzg0KJ14dZ5vd11ZRyYisbJ MWOIzwgoO+PdSowtz1eeRcxlIwF+b0fTrlmHd/0hUynqdbsoe2szcrWZ5838jr38b8hI 3Cf+vnhZLIEJAV/vIV4OnRlhOdn+HNSqOA9GDOwK502Sz4rjcs0i3q8prmqepccCLW/C O05Q== X-Gm-Message-State: AHQUAuZCjbC12zaYGncQ/jXEYZAgJdiwiOJ/LlS6dN+Bm6cbGeLLuxx1 4aKArXdnBBEPfnEHAr9vNLh/HKjDETlZEkhh7Ax5+A== X-Google-Smtp-Source: AHgI3IZNBYzVpPlEV/XegU5kLgP+0qizriA82KdSV6Ed1Lp6HlC7A8FPnkxKhJ4Qy0vk++7OMkXmXi3W5yZWBhePKXI= X-Received: by 2002:a24:a08a:: with SMTP id o132mr8447150ite.1.1549266620656; Sun, 03 Feb 2019 23:50:20 -0800 (PST) MIME-Version: 1.0 References: <8B717E7C-9C17-47E4-AAB6-5BF081D0C3A4@fb.com> In-Reply-To: <8B717E7C-9C17-47E4-AAB6-5BF081D0C3A4@fb.com> From: Miklos Szeredi Date: Mon, 4 Feb 2019 08:50:09 +0100 Message-ID: Subject: Re: Invalidating cached FUSE directory entries To: Chad Austin Cc: "linux-fsdevel@vger.kernel.org" , "caustin@gmail.com" Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Thu, Jan 31, 2019 at 2:57 AM Chad Austin wrote: > > On a recent kernel with readdir caching and FUSE_NO_OPENDIR_SUPPORT > (and this follow-on patch: > https://patchwork.kernel.org/patch/10785105/ ), I benchmarked our > source control FUSE filesystem. With hot caches and zero requests > being made to userspace, I could do a full directory crawl of a major > subset of our repository in under 3 seconds. When I ran the same test > against ext4 and btrfs, it took between 3 and 6 seconds. Awesome! > > However, though we were correctly sending FUSE_NOTIFY_INVAL_ENTRY > whenever changing a directory inode's entry, this did not flush the > readdir pagecache. It looks to me like FUSE_NOTIFY_INVAL_ENTRY only > invalidates the readdir cache if the dcache has an entry with the > given name. Whether that's true is entirely out of userspace's hands. > > We worked around it by also explicitly sending FUSE_NOTIFY_INVAL_INODE > once per inode if we ever sent FUSE_NOTIFY_INVAL_ENTRY. But this > increases our invalidation traffic and seems unnecessary. > > What do you think about having FUSE_NOTIFY_INVAL_ENTRY also > unconditionally invalidate the readdir cache? Makes sense. Thanks, Miklos