From owner-freebsd-hackers@freebsd.org Mon Mar 4 15:33:05 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 551BD1516375 for ; Mon, 4 Mar 2019 15:33:05 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) (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 3E7A96F6FD for ; Mon, 4 Mar 2019 15:33:04 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-f173.google.com with SMTP id z20so4678600ljj.10 for ; Mon, 04 Mar 2019 07:33:04 -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=0xe9UuPxJzxXPTEcF365k/2KkWtbYwZnhc36PLa+oL0=; b=Q1oPNOY2BLj2kS6KZC7udLvnYDbUxRzF0evzbSF5P+NbUOXky2YMZNQPwVygJVcWw/ Tz6giC0ng+XM3N6tnFo7odO2vIivHLDNCgR1VEiY0I0ZgkjcchXgGo5znNkzC2eCTYFi UiYRTIFoEaylJ01VuMEF5E7GdfB8BUriGVQzyKndIx/fGMctc6w+lCWAKsT/brEGzPWO hGyotD2f8sv3juV4bHmpNYPIpTdgqby0S0gZ/qZfM43Nc8CtZUn0L8etTMvsdFczmlop Qv3BZ3ItmD8mgjBxSY7RX2993bXqFGkTPtwShmnLiavf4XxOPBHc9SCeQWbvyG6mhpKy kunA== X-Gm-Message-State: APjAAAWN6p3FMl1LuAV4+wWPxsnvZw2b769NmuEsCbJy8IEO6LjXHLl3 1acb/AC00lE6vPCmv7OHFP8K5HhpTRzHAZKxCeo= X-Google-Smtp-Source: APXvYqxAJYg9J3WRZbRBomVy7W4CKuzLu4zrUozWbU0V6+Gc8tmQ6XTzvhBp6/3+/AQzCdr7BnipKwcdqReX8+hDnmE= X-Received: by 2002:a2e:1510:: with SMTP id s16mr10965232ljd.62.1551713078715; Mon, 04 Mar 2019 07:24:38 -0800 (PST) MIME-Version: 1.0 References: <20190303110346.GH68879@kib.kiev.ua> In-Reply-To: <20190303110346.GH68879@kib.kiev.ua> From: Alan Somers Date: Mon, 4 Mar 2019 08:24:27 -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: 3E7A96F6FD X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-3.26 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.994,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; IP_SCORE(-1.29)[ip: (-0.51), ipnet: 209.85.128.0/17(-3.84), asn: 15169(-2.03), country: US(-0.07)]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[173.208.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.97)[-0.970,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_COUNT_TWO(0.00)[2] 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: Mon, 04 Mar 2019 15:33:05 -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. I don't understand this objection. When you extract a tarball full of non-empty files, don't you still need to open every file to write its contents, creating a namecache entry for each one? > > > 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. >