From owner-freebsd-hackers@freebsd.org Sun Mar 3 16:02:27 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76CA0150F4E2 for ; Sun, 3 Mar 2019 16:02:27 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E644C89C18 for ; Sun, 3 Mar 2019 16:02:26 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-f194.google.com with SMTP id g80so2163275ljg.6 for ; Sun, 03 Mar 2019 08:02:26 -0800 (PST) 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=I9i2Bsej1cVHQ5NM52IjlaLqeWvyrxisw8H355lTI1g=; b=PqpfHPro9TOH1G0R/Hgzf9FFK4N8XExW7TPltsEr8dj7r4Yq5821JkUbsesuALPY5F 7JgLJIR/I667fJpEmPymaunhK3eZT1dUK0sz9PxMQh+OP6eSX7OzlZmFeheVhbGto22p DKjT2QMPB3TA3c+/I9CVr7oDFUJRwnvQMFXvowA1mYe1bTkMmI0XvVE5t17afTWNWD3i og1jIWTg8OEbOahoTroO6vxGEUOt83xKAoRlKzI/H26w/mzetTn8rrcewCtqDThxFNSc fYL4eeqyEbLlU5y1NpaWLpQyoU8iD9ci3qXL1RalSPgBHPs24p6C6H/T6WPMYIBbhjXs UHbw== X-Gm-Message-State: APjAAAXRqdUQsRLfizYhOfYLbG6rBGm/EzHeb/IsM9AG6HEhVAFqOgeh jMMD87qseKTjE02oNorIHOdGxMb3FZzO8o8QGxc= X-Google-Smtp-Source: APXvYqzOJFa2V4amUNR7ZKvz94vBiZ5LuyoZD4+uVpZW7mwcsZjlLziPi73MQx+sGbmtBbQTtzkPjZF0GSMCLxolKY8= X-Received: by 2002:a2e:1510:: with SMTP id s16mr8276238ljd.62.1551628938908; Sun, 03 Mar 2019 08:02:18 -0800 (PST) MIME-Version: 1.0 References: <20190303110346.GH68879@kib.kiev.ua> In-Reply-To: <20190303110346.GH68879@kib.kiev.ua> From: Alan Somers Date: Sun, 3 Mar 2019 09:02:07 -0700 Message-ID: Subject: Re: Adding namecache entries outside of vfs_lookup and vn_open ? To: Konstantin Belousov Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: E644C89C18 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.981,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2019 16:02:27 -0000 On Sun, Mar 3, 2019 at 4:03 AM Konstantin Belousov wrote: > > On Sat, Mar 02, 2019 at 06:02:06PM -0700, Alan Somers wrote: > > It looks like lookup and open are the only common vops that create new > > namecache entries. At least, those are the only ones that set > > MAKEENTRY in the cn_flags field. However, fuse(4)'s create-like > > operations (FUSE_CREATE, FUSE_SYMLINK, etc) all return enough > > information to create a namecache entry for the newly created file. > > As-is, an operation like FUSE_CREATE will almost always be followed up > > by a FUSE_LOOKUP, necessitating an extra round-trip to userland. > In VFS, creation of the new file is done by VOP_CREATE() after negative > VOP_LOOKUP(). VOP_CREATE() returns the new vnode that is installed into > file. [A flag VN_OPEN_NAMECACHE was added for vn_open_cred() which results > in created name entry insertion into namecache. It was done to handle > very specific situation in core dump code, which is no longer relevant. > The flag is still there.] > > Similar discussion occured some time ago. I think that the current > selection of the cases where namecache entry is created, is optimized > for the scenario where extracting large tarball does not largely affect > the non-directory elements of the cache. If you do such extraction, > it is unlikely that you will access most of the files shortly. > > > Would it be possible and wise to add these newly created entries to > > the namecache automatically? > Not from VFS, but the policy can be overriden by the filesystem by inserting > the elements into cache from VOPs as it finds suitable. So MAKEENTRY is just advisory, and there shouldn't be a problem with inserting cache entries from fuse_nop_create even if MAKEENTRY isn't set? I might try that. The penalty for not doing so is an extra trip to userland, which is greater than the penalty for other file systems not doing it. > > Does FUSE cache vnodes ? I would find aggressive caching on the kernel > side somewhat unexpected for it. No, it just uses the regular vnode cache. The unique things that it does is it caches file attributes within the vnode, and the daemon can request a timeout period for either the attr cache or the entry cache. When the timeout expires, the kernel is supposed to purge (or ignore) its cached values. -Alan