[Bugs] [Bug 1444892] When either killing or restarting a brick with performance.stat-prefetch on , stat sometimes returns a bad st_size value.

[bugzilla at redhat.com]

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

Ravishankar N <ravishankar at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |miklos.fokin at appeartv.com,
                   |                            |ravishankar at redhat.com
           Assignee|bugs at gluster.org            |ravishankar at redhat.com
              Flags|                            |needinfo?(miklos.fokin at appe
                   |                            |artv.com)



--- Comment #4 from Ravishankar N <ravishankar at redhat.com> ---
(In reply to miklos.fokin from comment #2)

> In afr_fsync_cbk, when receiving data from the bricks there are two times
> when the fstat data can get updated: first is the initial update, and then
> the one from the brick we selected to get the final data from.
> During the debugging I found that if the initial update is coming from the
> arbiter the size will be 0.
> If the brick we selected to get the final data from is down, we get a struct
> filled with zeroes, and an error value, thus we don't get a second update.

Hi Miklos, did you  observe while debugging that in afr_fsync_cbk(), the
'read_subvol' is indeed the brick you brought down? I haven't tried your test
yet but if a brick is brought down, then the read_subvol is updated on the next
lookup/inode_refresh where the brick is not marked readable any more until heal
is complete. So, if you brought down brick1, then the call to
afr_data_subvol_get() in afr_fsync_cbk() should give you brick2.

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