On 11/16/2010 03:07 PM, Stephan von Krawczynski wrote: > On Tue, 16 Nov 2010 08:51:17 -0800 > Jeff Anderson-Lee<jonah at eecs.berkeley.edu> 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
