[Bugs] [Bug 1593078] [GSS][SAS library corruption on GlusterFS]

[bugzilla at redhat.com]

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

Raghavendra G <rgowdapp at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|bugs at gluster.org            |rgowdapp at redhat.com



--- Comment #2 from Raghavendra G <rgowdapp at redhat.com> ---
(In reply to Raghavendra G from comment #24)
> (In reply to Csaba Henk from comment #23)
> 
> The other work-around (if the hypothesis is true) is to turn on
> cluster.lookup-optimize to true. When lookup-optimize is turned on
> dht-lookup doesn't resort to lookup-everywhere on not finding src on
> src-hashed. Instead it just conveys a failure to application. Since lookup
> won't reach src-cached, it won't find the hard-link.

Since patch [1] We've made hashed-subvol as the subvol to take locks during
rename. This means presence of entrylks on hashed-subvol on the basename of
src/dst of rename indicates a rename in progress. On observing locks,
dht_lookup can,

* acquire entrylk on parent inode with basename
* Do the lookup
* unlock entrylk
* unwind the lookup

This will help lookup to synchronize with rename and hence to preserve the
atomicity of rename. Note that this algorithm works even when first lookup
fails with ENOENT. Also, the cost of synchronization is isolated to the lookups
happening only during rename. Lookups happening outside rename window won't
suffer the cost of synchronization.

This will be a code change and I'll be submitting a patch to do this.
[1] https://review.gluster.org/19547/

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