gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jeff Darcy
Subject: Re: [Gluster-devel] Proposal to change locking in data-self-heal
Date: Tue, 21 May 2013 10:05:59 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]