[Gluster-devel] Client side translators doubt

Anand Avati anand.avati at gmail.com
Wed Jan 16 04:12:51 UTC 2013

On Tue, Jan 15, 2013 at 12:29 PM, Jeff Darcy <jdarcy at redhat.com> wrote:

> On 01/15/2013 01:43 PM, Gustavo Bervian Brand wrote:
>>    I'm trying some volumes configurations with 2 nodes, each one having a
>> gluster client and server running.
>>    Both clients have each one a volume related to my translator, which
>> has as
>> sub volumes two "protocol/client" subvolumes (one subvol pointing to the
>> local
>> node's IP/vol and another pointing to the remote node IP/vol).
>>    This works OK, and here comes the problem: when I try to change the
>> local
>> vol at the client side from a "protocol/client" type to a "posix" type
>> the read
>> breaks with -1 (operation not permitted).
> You don't say what version you're using, but could it be one of these?
>         https://bugzilla.redhat.com/**show_bug.cgi?id=868478<https://bugzilla.redhat.com/show_bug.cgi?id=868478>
>         (patch for previous at http://review.gluster.org/#**change,4114<http://review.gluster.org/#change,4114>
> )
>         https://bugzilla.redhat.com/**show_bug.cgi?id=822995<https://bugzilla.redhat.com/show_bug.cgi?id=822995>
> 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?
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130115/ec1e5be3/attachment-0001.html>

More information about the Gluster-devel mailing list