Adding namecache entries outside of vfs_lookup and vn_open ?

[Alan Somers]

On Mon, Mar 4, 2019 at 8:42 AM Konstantin Belousov <kostikbel at gmail.com> 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 <kostikbel at gmail.com> 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