On Tue, Jan 15, 2013 at 12:29 PM, Jeff Darcy
<address@hidden> 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).
https://bugzilla.redhat.com/show_bug.cgi?id=868478
(patch for previous at http://review.gluster.org/#change,4114)
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.
Avati