<br><br><div class="gmail_quote">On Fri, May 6, 2011 at 7:11 PM, Jeff Darcy <span dir="ltr"><<a href="mailto:jdarcy@redhat.com">jdarcy@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="im">On 05/05/2011 04:23 PM, Edward Shishkin wrote:<br>
> The straightforward solution is to serialize read-modify-writes.<br>
> I wonder if GlusterFS has any per-file serialization means,<br>
> that would allow to resolve this problem. Or maybe there are<br>
> possibilities to create such means. Any hints would be highly<br>
> appreciated.<br>
<br>
</div>At a first approximation, you could just wrap the read-modify-write in<br>
POSIX locks. That would conflict with other uses of POSIX locks, though,<br>
and might not address the issue of "self-conflict" induced e.g. by some<br>
of the performance translators issuing parallel writes to the same fd.<br>
There is an "oplock" translator in CloudFS which was co-developed with<br>
the encryption translator you're working on and which attempts to<br>
provide the necessary conflict detection without scalability-destroying<br>
serialization. The code does need some improvement, though, as has been<br>
discussed on the cloudfs-devel thread you started at<br>
<a href="https://fedorahosted.org/pipermail/cloudfs-devel/2011-May/000038.html" target="_blank">https://fedorahosted.org/pipermail/cloudfs-devel/2011-May/000038.html</a>.<br>
In particular, we need to address not just race conditions but also e.g.<br>
forward-progress guarantees, and (as I said in that thread) I think<br>
judicious use of server-side request queuing is the way to do that.<br><br></blockquote><div><br></div><div>You could also look at inodelk() FOP which gets serviced by the locks translator. inodelk() uses a domain based lock space (domain name could be your subvolume name) and is isolated from user application's POSIX fcntl based locks.</div>
<div><br></div><div>Avati</div><div> </div></div>