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.
