|
From: | Anand Avati |
Subject: | Re: [Gluster-devel] Proposal to change locking in data-self-heal |
Date: | Tue, 21 May 2013 12:49:19 -0700 |
On 05/21/2013 09:10 AM, Pranith Kumar Karampuri wrote:This is two changes for two scenarios:
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.
* 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.
[Prev in Thread] | Current Thread | [Next in Thread] |