<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 22, 2013 at 5:57 AM, Pranith Kumar Karampuri <span dir="ltr"><<a href="mailto:pkarampu@redhat.com" target="_blank">pkarampu@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
----- Original Message -----<br>
> From: "Anand Avati" <<a href="mailto:anand.avati@gmail.com">anand.avati@gmail.com</a>><br>
> To: "Jeff Darcy" <<a href="mailto:jdarcy@redhat.com">jdarcy@redhat.com</a>><br>
> Cc: "Pranith Kumar Karampuri" <<a href="mailto:pkarampu@redhat.com">pkarampu@redhat.com</a>>, "Anand Avati" <<a href="mailto:aavati@redhat.com">aavati@redhat.com</a>>, "Raghavan Pichai"<br>
> <<a href="mailto:rpichai@redhat.com">rpichai@redhat.com</a>>, "Ravishankar Narayanankutty" <<a href="mailto:ranaraya@redhat.com">ranaraya@redhat.com</a>>, "devel" <<a href="mailto:gluster-devel@nongnu.org">gluster-devel@nongnu.org</a>><br>
> Sent: Wednesday, May 22, 2013 1:19:19 AM<br>
> Subject: Re: [Gluster-devel] Proposal to change locking in data-self-heal<br>
><br>
> On Tue, May 21, 2013 at 7:05 AM, Jeff Darcy <<a href="mailto:jdarcy@redhat.com">jdarcy@redhat.com</a>> wrote:<br>
><br>
> > On 05/21/2013 09:10 AM, Pranith Kumar Karampuri wrote:<br>
> ><br>
> >> scenario-1 won't happen because there exists a chance for it to acquire<br>
> >> truncate's full file lock after any 128k range sync happens.<br>
> >><br>
> >> Scenario-2 won't happen because extra self-heals that are launched on the<br>
> >> same file will be blocked in self-heal-domain so the data-path's locks are<br>
> >> not affected by this.<br>
> >><br>
> ><br>
> > This is two changes for two scenarios:<br>
> ><br>
> > * Change granular-lock order to avoid scenario 1.<br>
> ><br>
> > * Add a new lock to avoid scenario 2.<br>
> ><br>
> > I'm totally fine with the second part, but the first part makes me a bit<br>
> > uneasy. As I recall, the "chained" locking (lock second range before<br>
> > unlocking the first) was a deliberate choice to avoid windows where<br>
> > somebody could jump in with a truncate during self-heal. It certainly<br>
> > wasn't the obvious thing to do, suggesting there was a specific reason.<br>
><br>
><br>
> Chained locking really was to avoid the start of a second self-heal while<br>
> one is in progress. By giving up the big lock (after holding the small<br>
> lock), regional operations can progress but the second self-heal waiting to<br>
> hold the big lock is still held off. Truncating isn't really an issue as<br>
> long as the truncate transaction locks from new EOF till infinity (which it<br>
> is) and self-heal will not race in those regions. Of course, with chained<br>
> locking, full-file truncates can starve.<br>
><br>
> It's not obvious what use case Pranith is facing where self-heal and<br>
> ftruncate() are competing. Is it just an artificial/hand-crafted test case,<br>
> or a real-life access pattern?<br>
<br>
</div></div>artificial.<br>
<div class="im"><br>
><br>
><br>
> > Until we recall what that reason was I don't think we can determine<br>
> > whether this is a bug or a feature. If it's a feature, or if we don't<br>
> > know, this change is likely to break something instead of fixing it.<br>
><br>
><br>
> The sole reason was to prevent the start of a second self-heal. Having<br>
> self-heals serialize in a separate domain solves the problem (except if we<br>
> are looking at runtime compatibility across multiple versions in this<br>
> scenario.. aargh!)<br>
<br>
</div>So you guys are OK with this proposal if we solve version compatibility issues?<br><br></blockquote><div><br></div><div style>I guess you can even just ignore the backward compatibility issue in this case. Old servers will "safely" block themselves against the big data-lock causing starvation just the way things work today. Once all servers are upgraded, all self-heals will gracefully block themselves in the new domain. There isn't much compatibility handling actually.</div>
<div style><br></div><div style>Avati</div><div style><br></div></div></div></div>