Gluster users - Mar 2013 - Writing to the data brick path instead of fuse mount?

So I noticed if I create files in the data brick path, the files travel to
the other hosts too.  Can I use the data brick path instead of using a fuse
mount instead.  I'm running two machines with two replicas.  What happens
if I do stripes?  Some machines are clients as well as servers.  Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130319/a12e89a8/attachment.html>

On 03/20/2013 10:13 AM, Ziemowit Pierzycki wrote:
> So I noticed if I create files in the data brick path, the files 
> travel to the other hosts too.  Can I use the data brick path instead 
> of using a fuse mount instead.  I'm running two machines with two 
> replicas.  What happens if I do stripes?  Some machines are clients as 
> well as servers.  Thanks!
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users
Ziemowit Pierzycki,
       The behaviour you are observing is added to handle the following 
corner use case:
In case of split-brain/gfid mismatch of a file, if a file is deleted on 
one of the bricks the file is replicated to the other machine.
That said Adding data to backend directly will disable the ability of 
replication to decide which copy of the file is good vs bad when the 
file needs to be self-healed. So please use fuse mount data path.

Pranith
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130320/0d7510c1/attachment.html>

On 03/20/2013 12:43 AM, Ziemowit Pierzycki wrote:
> So I noticed if I create files in the data brick path, the files travel
> to the other hosts too.  Can I use the data brick path instead of using
> a fuse mount instead.  I'm running two machines with two replicas. 
What
> happens if I do stripes?  Some machines are clients as well as servers.
If files written that way are replicated, it's almost by accident (e.g.
by code that's there to handle a more legitimate case as Pranith
mentions).  Writing directly to the bricks is kind of editing a
database's files directly while the database still has them open.  In
our case, because writing that way bypasses a bunch of translators, it
won't work with striping, quota, or even ACLs.  Worst of all, it will
bypass all of the mechanisms we use to prevent split brain - locking,
change logging, quorum enforcement.  This creates myriad opportunities
for split brain to occur, if anything should happen between the time a
file is written "behind our backs" and whenever it gets replicated
(which really is "whenever" in this case).

In general, the contents of bricks are "off limits" as long as that
brick is part of a volume.  Unfortunately there are still a few cases
where manual repair requires such direct access, but only under
controlled conditions.  Some day we'll finish adding code to deal with
those same case "inline" (i.e. through a mountpoint) and use SELinux
to
disable brick access other than through glusterfsd.