From owner-freebsd-hackers@freebsd.org Sun Mar 3 11:03:55 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 9523F1506379 for ; Sun, 3 Mar 2019 11:03:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BF52C804F5; Sun, 3 Mar 2019 11:03:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x23B3lct050818 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 3 Mar 2019 13:03:50 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x23B3lct050818 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x23B3kgh050817; Sun, 3 Mar 2019 13:03:46 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 3 Mar 2019 13:03:46 +0200 From: Konstantin Belousov To: Alan Somers Cc: FreeBSD Hackers Subject: Re: Adding namecache entries outside of vfs_lookup and vn_open ? Message-ID: <20190303110346.GH68879@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home 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 11:03:55 -0000 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. Does FUSE cache vnodes ? I would find aggressive caching on the kernel side somewhat unexpected for it.