[Gluster-devel] Proposal to change locking in data-self-heal

Jeff Darcy jdarcy at redhat.com
Tue May 21 14:05:59 UTC 2013


On 05/21/2013 09:10 AM, Pranith Kumar Karampuri wrote:
> scenario-1 won't happen because there exists a chance for it to acquire
> truncate's full file lock after any 128k range sync happens.
>
> Scenario-2 won't happen because extra self-heals that are launched on the
> same file will be blocked in self-heal-domain so the data-path's locks are
> not affected by this.

This is two changes for two scenarios:

* Change granular-lock order to avoid scenario 1.

* Add a new lock to avoid scenario 2.

I'm totally fine with the second part, but the first part makes me a bit 
uneasy.  As I recall, the "chained" locking (lock second range before unlocking 
the first) was a deliberate choice to avoid windows where somebody could jump 
in with a truncate during self-heal.  It certainly wasn't the obvious thing to 
do, suggesting there was a specific reason.  Until we recall what that reason 
was I don't think we can determine whether this is a bug or a feature.  If it's 
a feature, or if we don't know, this change is likely to break something 
instead of fixing it.




More information about the Gluster-devel mailing list