Re: cache fixes (redux)

[Dominique Martinet <asmadeus@codewreck.org>]

Hi Eric!

Eric Van Hensbergen wrote on Tue, Dec 26, 2023 at 10:13:20AM -0600:
> - The fact that we never seem to use multi-walk (this isn't a cache
> specific problem, it actually is somewhat worse in non-cache mode).
> This seems to be because fid_lookup goes recursive before entering
> multiwalk.  This should be a fairly simple fix - I'm just going to add
> an argument to limit recursion, but I'm noodling on whether we need
> that path a bit first.

I'm not sure multi-walk is possible in practice: even opening a file
directly through e.g. cat /mnt/long/path/to/file will have the VFS check
permissions along the path, so the VFS will need to stat all elements
along the way.

If you can get it to work though it's certainly worth implementing the
possibility, let's give it a try.


> - figure out why even in loose mode we seem to be sending a lot of
> stat/getattr -- this seems to be related to some code that came in
> with the cache code.  It seems we almost always stat/getattr because
> we are constantly creating new inodes.  There's some comments in
> vfs_inode.c:755 that talk about needing to do this for parallel lookup
> -- but this all seems like a hack.  Anyone have better insight into
> why we need this?  We always to the stat/getattr to retreive the stat
> to compare against because we don't trust qid.path -- which I think is
> wrong.  If there is an issue with unlinked files, I think we can do
> something smarter to differentiate them, maybe using a qid.type

Hmm in loose mode we definitely should be reusing the inodes...
No idea why we had this in the first place, I'd say rip it out and
compare?

>      - QUESTION: it seems like P9_QTLINK and P9_QTSYMLINK are no
> longer used, can these be recovered?  I was thinking of reusing one of
> these to mark unlinked files which we could do a more comprehensive
> compare for if its actually necessary.

Since we don't support reconnects, unlinked files have been working just
fine with servers that keep the underlying files open (e.g. qemu)

What's your plan exactly?

We don't have any way of driving protocol changes forward (and there's
no compatibility negotiation on client connect...), but I recall
Christian also was looking forward to some other changes so we might
want to try to move this forward again...


-- 
Dominique Martinet | Asmadeus