[Bugs] [Bug 1773476] gluster does not return correct filesize and blocksize after ftruncate

[bugzilla at redhat.com]

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



--- Comment #10 from Raghavendra G <rgowdapp at redhat.com> ---
(In reply to Ravishankar N from comment #8)
> (In reply to Ravishankar N from comment #5)
> 
> So the reason it is not happening in 3.12.x is because it did not have the
> function rda_inode_ctx_update_iatts() introduced by the commit "*c9bde3021 -
> performance/readdir-ahead: keep stats of cached dentries in sync with
> modifications"
> 
> What is happening is this:
> -When consistent-metadata is enabled, afr calls afr_zero_fill_stat() in its
> truncate call back and sets ctime and nlink to zero in the postbuf. This
> behaviour is already there in glusterfs 3.12  This forces fuse to trigger a
> lookup which hits AFR (and thus the bricks) and the application gets the
> current ia_size when it does the stat.
> -But in the current code-base, when ctime is zero, the function
> rda_inode_ctx_update_iatts() zeroes out everything else also in the postbuf
> except gfid and ia_type. This somehow is not causing FUSE to trigger a
> lookup.
> 
> Raghavendra, is there some field in the postbuf that we need to retain and
> not zero out (in addition to the gfid and ia_type) in
> rda_inode_ctx_update_iatts() so that fuse sends a lookup when application
> does a stat?

comment #5 says things work fine if we wait for 1s which is incidentally
'attribute-timeout' default value. When we wrote that patch in readdir-ahead,
we were expecting kernel to only refresh the 'entry' (path to inode resolution)
without touching the 'attributes' (rest of the stat). It looks like something
is broken there.

Just to get more details, when was the last stat sent (before zeroed out
postbuf was sent)? Is the 1s you mentioned was,
1. after the lookup/readdirp response that returned zeroed out stat (except for
gfid and type)?
2. after a valid lookup/readdirp/stat/fstat response that returned a completely
valid stat (all fields are valid)?

A more correct way to make sure kernel forgets the inode and initiates a lookup
(without being subjected to various timeouts like attribute-timeout,
entry-timeout, md-cache-timeout) is to call inode_invalidate on the inode.

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