bazil
Let FS opt out of automatic Attr filling in Setattr/Lookup/Create/Mkdir/Symlink
What's the right mechanism for the FS to convey that it has already filled Attr, and we shouldn't overwrite it? Attr.Valid != 0? What are the exact semantics of validity time of nothing, is that ever meaningful to communicate to the kernel?
I'm observing an unexpected behavior that seems related to this issue.
If my file system implements the NodeRequestLookuper and not the NodeStringLookuper, this Lookup function on the Node receiver is called. This function, as far as I understand, is expected to populate the Attr field of the response passed as argument with the metadata attributes of the receiver.
However, when processing a fuse.LookupRequest the serve function calls saveLookup which in turn calls nodeAttr. nodeAttr systematically calls the Attr function on the node receiver. As a result, the metadata already returned by Lookup and present in the response to this request is ignored and requested again.
So, my questions are:
Q1: Is this intended and my file system should not bother populating the resp.Attr field when implementing NodeRequestLookuper interface since anyway the Attr will be called on the same node later on?
Q2: what is the meaning of the field EntryValid in LookupResponse? Is this for the file system to inform bazil.org/fuse how much time it should cache this metadata or is it for bazil.org/fuse to convey some information to the file system, and if so, how should the file system interpret that?
This issue is about possibly changing the logic to skip the Attr call if the Lookup/Create/Mkdir already filled in the information, but it's not clear at this time whether that's easily doable, or even worth it. So, for the purposes of code being written right now, Attr will always be called, and should be the one filling in those fields. You need to implement Attr anyway, so in practice that's the easy way.
Q1: You should let the Attr call fill those fields.
Q2: The cache is in the kernel. A default value (currently 1 minute) is set in that field before your Attr method is called, so you can just ignore it if you don't care about the details.
I would like to ask something based on the conversation above. Regarding EntryValid in LookupResponse (Q2), I am confused if there is a way to modify its value and moreover to ignore this delay? Thank you in advance!
@tkatsivas Just set resp.EntryValid in your Lookup method. Not sure why you're calling it a "delay", it's expiry for the kernel dentry name cache. After that time, you'll get a new Lookup (when the name is next looked up).
@tv42 thank you very much for your response. I have constructed a Lookup method of that kind: Lookup(ctx context.Context, name string). Inside that method I set resp := &fuse.LookupResponse{} and I try unsuccessfully to modify resp.EntryValid. Actually, according to the logs of my implementation, I can see that except for the first time, a new Lookup method is called after 1 minute. Therefore when i try to access my value, during that 1 minute, using "cat" command, I get a cached value and not an updated. If I have understood correct, this happens due to that EntryValid variable, that's why I called it "delay", wrongly.
@tkatsivas I'm confused about what you mean by "try unsuccessfully to modify resp.EntryValid". Did you manage to modify it or not? Did your modification just have no effect?
This seems to have nothing to do with this particular issue; if you think you've found a bug where EntryValid is not respected, please open a new issue. Ideally with steps to reproduce the bug.