From owner-freebsd-hackers@freebsd.org Mon Mar 4 16:07:46 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 3D749151843C for ; Mon, 4 Mar 2019 16:07:46 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) (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 C43F2709AD for ; Mon, 4 Mar 2019 16:07:45 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-f196.google.com with SMTP id q128so4791366ljb.11 for ; Mon, 04 Mar 2019 08:07:45 -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=8+1TJBVjbUBvS7tBG9NXOZphS4GQaRY9lmI351kexVE=; b=cokLpiY0xQ3ht8M9pcHKKOCezhWhpWyG94DQApcLqIk6xuasDsPAMjh0k9rjMh4w+6 Dl2ldk6Wcvi5Pc/nitNicwI/z7wzhqt+lO6ot6B5EL5Xc2YV78eO1HguP1YLPL/4dJpN Td+lYK9RjXg0pQQl8tCVdDHJsIVMF8iPS2VwPwazfY0mDpNrJZq1PFvh+p8dD37CEejk kC/SPA697sclZpdm3XcfyA6RcIBIyfQVhlQmhpNCvXPM4pslFIFwLdt3qxTHxbf/wuC4 8VE7JUEg4d+URIVxNd5lbeUcu7IW90y6gQzrQWxGL6hqGK2ZkOSPRbqfK/uC5wv4dtSP LTQw== X-Gm-Message-State: APjAAAXsvSkn6INoWoVyorWZKy1zjZoMtPPfuE/n+ZRL7SCa6IPz3szo H6nm/pBj+U1WKI2oQflzuzZpVbC0HBnlQPEZKX0= X-Google-Smtp-Source: APXvYqxdwyciuOwvPOfSbKNTvvTyw4WTeYotf6KOGaNWO4JZhU9K8JcLg9UicM4KDXJZqzLPEXzsz5IFK+uCLTsIT+s= X-Received: by 2002:a2e:1510:: with SMTP id s16mr11056159ljd.62.1551715195466; Mon, 04 Mar 2019 07:59:55 -0800 (PST) MIME-Version: 1.0 References: <20190303110346.GH68879@kib.kiev.ua> <20190304154212.GP68879@kib.kiev.ua> In-Reply-To: <20190304154212.GP68879@kib.kiev.ua> From: Alan Somers Date: Mon, 4 Mar 2019 08:59:43 -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: C43F2709AD 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_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.985,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: Mon, 04 Mar 2019 16:07:46 -0000 On Mon, Mar 4, 2019 at 8:42 AM Konstantin Belousov wrote: > > On Mon, Mar 04, 2019 at 08:24:27AM -0700, Alan Somers wrote: > > On Sun, Mar 3, 2019 at 4:03 AM Konstantin Belousov wrote: > > > 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? > No, you don't. > > Typically, when archiver parsed the stream and noted that there is a file > to create with a content, it > - opens the file, and gets the file descriptor returned to usermode. > Internally, kernel does (vn_open_cred()) > namei() <- this call returns no vnode because the file is non-existent, > and does not create negative cache entry, see NOCACHE > argument for cn_flags. > VOP_CREATE() <- creating the file, again not caching > assign the vnode returned, to the file > - now the process has the descriptor for writes, but namecache entry is > still not installed. > - content is written, file is closed. Ok, that make sense. So I guess the problem only really applies to filetypes like symlinks that can't create-and-open. But in the tarball case, you wouldn't need to access the symlink again anyway. -Alan