On 11/16/2010 03:07 PM, Stephan von Krawczynski wrote:
On Tue, 16 Nov 2010 08:51:17 -0800
Jeff Anderson-Lee<[email protected]> wrote:
On 11/16/2010 05:36 AM, Stefano Baronio wrote:
Hi MArtin,
the XenServer Dom0 is 32bit whilst the hypervisor is 64 bit.
You need to know it when you install third part sw on the host.
http://forums.citrix.com/thread.jspa?threadID=269924&tstart=0
So I need the 32bit compiled version to be able to mount glusterfs directly
from the XenServer host.
The built-in NFS module is typically as fast or faster than using the
fuse wrapper on the client side. So the best way to support 32-bit
clients is likely via NFS.
NFS is really something completely different. And - what is also ignored - the
infrastructure usage is completely different when using nfs. nfs does not
replicate at the client side, which means that the data paths explicitly built
for client replication are useless for nfs. Using the nfs translator leads to
server-server replication. For that case a data path exclusively used for this
server traffic would be best (because it cannot interfere with 64 bit client
replication).
So if you happen to upgrade a 2.0.9 setup with 64 bit servers and 64 as well
as 32 bit clients you have to redesign the network for best performance _and_
glusterfsd on the servers have to use the shortest data path for the nfss'
data replication (which I don't know if they are able to do that at all).
In other words: whereas the setup in 2.0.9 was clear and simple, the very same
usage case in 3.X is a _mess_.
Obviously nobody really thought about that - unbelievable for me as it is
really obvious. But I got accustomed to that situation because up to the
current day there is no solution for another most obvious problem: which files
are not in sync in a replication setup? There is no trivial answer to this
question I already brought up in early 2.X development phase...
How can you sell someone a storage platform if you're unable to answer such an
essential question? Really, nobody needed auto-healing. All you need is the
answer to this question and then stat exactly this file list at a time _of
your choice_.
The good thing about 2.0.X was that you as an admin had quite full control
over things. in 3.X you have exactly nothing, the deamons are talking with
each other about whatever and hopefully things work out. That is no setup I
want to be an admin.
Regards,
Stephan
Stephan -
Based on your feedback, and from other members of the community we have
opened discussions internally around adding support for a 32-bit client.
We have not made a decision at this point, and I can't make any
guarantees but I will do my best to get it added to the next version of
the product (3.1.2, (3.1.1 is feature locked)).
On the sync question you brought up that is only an issue in the rare
case of split brain (if I understand the scenario you've brought up).
Split brain is a difficult problem with no answer right now. Gluster 3.1
added much more aggressive locking to reduce the possibility of split
brain. The process you described as "...the deamons are talking with
each other about whatever..." will also reduce the likelihood of split
brain by eliminating the possibility that client or server vol files are
not the same across the entire cluster, the cause of a vast majority of
split brain issues with Gluster.
Auto heal is slow, we have some processes along the lines you are
thinking, please let me know if these address some of your ideas around
stat -
#cd <gluster mount>
#find ./ -type f -exec stat /<backend device>’{}’ \; this will heal only
the files on that device.
If you know when you had a failure you want to recover from this is even
faster -
#cd <gluster mount>
#find ./ -type f -mmin <minutes since failure+ some extra> -exec stat
/<backend device>’{}’ \; this will heal only the files on that device
changed x or more minutes ago.
Thanks,
Craig
-->
Craig Carl
Senior Systems Engineer
Gluster
_______________________________________________
Gluster-users mailing list
[email protected]
http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
