Adding namecache entries outside of vfs_lookup and vn_open ?

[Alan Somers]

On Sun, Mar 3, 2019 at 4:03 AM Konstantin Belousov <kostikbel at gmail.com> 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.
>