Hello,<div><br></div><div> Actually I didn't give much context, sorry. I'm using the code from gluster 3.3 around August 28th 2012. </div><div><br></div><div> The translator I'm working with uses only 3 other types of translator for now, basically the client, server and posix ones. So, there's not much in the middle to deal with now, and that's why I was questioning that.</div>
<div> I took a look at the bugs mentioned, applied the related patches on my code tree, but the error is not the same. </div><div> About the gain in performance Jeff Dardy questioned, probably it doesn't worth so much really, but it was more of a technical doubt for now.</div>
<div> </div><div> Finally, let's get back to my original configuration with both subvolumes as "protocol/client" types: it works ok until I try something unusual, which is pointing at the server side of both nodes their "posix" type subvolumes to the same shared path. This path is a mount point shared by both nodes through a lustre FS. In this case, both posix subvolumes, at the backend, are writing to the same place. Should I expect this to work without problems or changes at the posix translator would be necessary?</div>
<div> I know the scenario is unusual and you'd ask why using gluster over lustre, but I'm working with the idea of federation of distributed file systems, using gluster and a new translator to allow the expansion of an installed DFS like lustre to use with some other nodes at another cluster.</div>
<div><br></div><div>Thanks,</div><div>Gustavo Brand</div><div>---------------------------------------------------------------------------------</div>
<br><br><div class="gmail_quote">On Wed, Jan 16, 2013 at 5:12 AM, Anand Avati <span dir="ltr"><<a href="mailto:anand.avati@gmail.com" target="_blank">anand.avati@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div><div class="h5">On Tue, Jan 15, 2013 at 12:29 PM, Jeff Darcy <span dir="ltr"><<a href="mailto:jdarcy@redhat.com" target="_blank">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>On 01/15/2013 01:43 PM, Gustavo Bervian Brand wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm trying some volumes configurations with 2 nodes, each one having a<br>
gluster client and server running.<br>
<br>
Both clients have each one a volume related to my translator, which has as<br>
sub volumes two "protocol/client" subvolumes (one subvol pointing to the local<br>
node's IP/vol and another pointing to the remote node IP/vol).<br>
<br>
This works OK, and here comes the problem: when I try to change the local<br>
vol at the client side from a "protocol/client" type to a "posix" type the read<br>
breaks with -1 (operation not permitted).<br>
</blockquote>
<br></div>
You don't say what version you're using, but could it be one of these?<br>
<br>
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=868478" target="_blank">https://bugzilla.redhat.com/<u></u>show_bug.cgi?id=868478</a><br>
(patch for previous at <a href="http://review.gluster.org/#change,4114" target="_blank">http://review.gluster.org/#<u></u>change,4114</a>)<br>
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=822995" target="_blank">https://bugzilla.redhat.com/<u></u>show_bug.cgi?id=822995</a><br>
<br>
In general, going directly to storage/posix seems ill warranted. It bypasses a bunch of translators like marker and access-control, for example. As we go forward there are likely to be even more "helper" translators for UID mapping, coordination for client-side encryption or erasure coding. Since it's not possible to create such a configuration through the CLI or other supported tools, it's not going to work properly when configurations change, either. Is it really worth all that, for what is likely to be a modest performance gain in most cases?<br>
<br></blockquote><div><br></div></div></div><div>All what Jeff says is valid. And, with the configuration described above, you end up with two instances of translator stacks exporting the same directory. One stack which is the local client which has a storage/posix at the bottom. The other stack is the brick which exports it for the second machine to connect via RPC. This results in two instances of locks translator each granting locks to respective clients without contending -- resulting in split brains and what not.</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>Avati </div></font></span></div>
<br>_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</a><br>
<a href="https://lists.nongnu.org/mailman/listinfo/gluster-devel" target="_blank">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br>
<br></blockquote></div><br>