[Bugs] [Bug 1630804] libgfapi-python: test_listdir_with_stat and test_scandir failure on release 5 branch

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1630804



--- Comment #22 from Shyamsundar <srangana at redhat.com> ---
(In reply to Raghavendra G from comment #21)
> (In reply to Shyamsundar from comment #16)
> > Based on comment #14 and comment #15, here is what I think we need to
> > answer, and also some possible thoughts:
> > 
> > 1) What is the contract between application calling glfs_readdirplus(_r) and
> > gfapi?
> > 
> > IMO,
> > - return entry with known stat information about the same
> > 
> > 2) What is the contract between various xlators and returned iatt
> > information and inode information?
> > - iatt validity seems to be ctime check, which is not the way forward, we
> > need to adapt to IATT_*_VALID flags in the future
> 
> +1

This could/would be the future, for now I think we need to work with ctime and
not flags, as when readdir-ahead is not present in the stack and we fix
readdir-ahead to return the flags, this assumption would break again and fail.

> 
> > - inode NULL or not? Currently as the write has occured there would be an
> > inode linked and returning a NULL seems logically incorrect, iatt
> > invalidation seems to be the better option IMO
> > - Du?
> 
> This can be done. However, not sure about the scope of change as the present
> code implicitly assumes entry->inode being NULL as a proxy for stat not
> present.

I suggest iatt->ia_ctime being 0 as the trigger, which I understand is done in
other places.

If we agree to the above, changes would be in gfapi only, to resolve/stat the
inode again for iatt information.

Also, we need to conclude fast, just so we can release with the fix. Unless
there is disagreement that this is a blocker.

> 
> > 
> > 3) What is the contact between protocol layer (in this case gfapi) and
> > xlator?
> > - I would assume it is the same as (2) and by protocol I mean
> > gfapi/FUSE(xlator) etc.
> > 
> > From an iatt and its validity fields, we need to adapt and address the
> > IATT_*_VALID flags across the stack, and take this as the contract forward,
> > but ca

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.