Hi Roberto, Try to reverse mirror-0 and mirror-1 such that mirror-1 is the first in the list. Does this make a difference? On May 26, 2010, at 2:21 AM, Roberto Lucignani wrote: > Hi Bala, > thank you very much for your reply. Yes I tried both methods, one building a > vol file and one retrieving the configuration from the server and both work > fine > > However my problem do not regards the mount process but it regards the spof > represented by node01. If it is unavailable I can't access my volume. > > Why this ? and why it happens only with the first node ? > > Regards > M4dG > > -----Messaggio originale----- > Da: Bala.JA [mailto:bala at gluster.com] > Inviato: domenica 23 maggio 2010 20.58 > A: roberto.lucignani at caleidos.it > Cc: gluster-users at gluster.org > Oggetto: Re: SPOF question > > > Hi Roberto, > > Gluster Storage Platform provides client volume spec file through server for > > created volumes. > > You can mount using > > mount -t glusterfs <server>:<volume>-<transport> <your-mount-point> > > for example, > mount -t glusterfs node01:gluster01-tcp /mnt/gluster01 > > Its not required to write your own spec file for mounting it. > > Thanks, > > Regards, > Bala > > > > Roberto Lucignani wrote: >> Hi all, >> >> I installed two Gluster Storage Platorm 3.0.4 on two servers node01 e >> node02. >> >> I created a volume called gluster01 than I mounted it on a Debian box in >> this way: >> >> >> >> mount -t glusterfs /etc/glusterfs/gluster01-tcp.vol /mnt/gluster01/ >> >> >> >> the gluster01-tcp.vol is the following: >> >> >> >> >> >> volume 192.168.0.200-1 >> >> type protocol/client >> >> option transport-type tcp >> >> option remote-host 192.168.0.200 >> >> option transport.socket.nodelay on >> >> option transport.remote-port 10012 >> >> option remote-subvolume brick1 >> >> end-volume >> >> >> >> volume 192.168.0.200-2 >> >> type protocol/client >> >> option transport-type tcp >> >> option remote-host 192.168.0.200 >> >> option transport.socket.nodelay on >> >> option transport.remote-port 10012 >> >> option remote-subvolume brick2 >> >> end-volume >> >> >> >> volume 192.168.0.201-1 >> >> type protocol/client >> >> option transport-type tcp >> >> option remote-host 192.168.0.201 >> >> option transport.socket.nodelay on >> >> option transport.remote-port 10012 >> >> option remote-subvolume brick1 >> >> end-volume >> >> >> >> volume 192.168.0.201-2 >> >> type protocol/client >> >> option transport-type tcp >> >> option remote-host 192.168.0.201 >> >> option transport.socket.nodelay on >> >> option transport.remote-port 10012 >> >> option remote-subvolume brick2 >> >> end-volume >> >> >> >> volume mirror-0 >> >> type cluster/replicate >> >> subvolumes 192.168.0.201-1 192.168.0.200-1 >> >> end-volume >> >> >> >> volume mirror-1 >> >> type cluster/replicate >> >> subvolumes 192.168.0.201-2 192.168.0.200-2 >> >> end-volume >> >> >> >> volume distribute >> >> type cluster/distribute >> >> subvolumes mirror-0 mirror-1 >> >> end-volume >> >> >> >> volume readahead >> >> type performance/read-ahead >> >> option page-count 4 >> >> subvolumes distribute >> >> end-volume >> >> >> >> volume iocache >> >> type performance/io-cache >> >> option cache-size `echo $(( $(grep 'MemTotal' /proc/meminfo | sed >> 's/[^0-9]//g') / 5120 ))`MB >> >> option cache-timeout 1 >> >> subvolumes readahead >> >> end-volume >> >> >> >> volume quickread >> >> type performance/quick-read >> >> option cache-timeout 1 >> >> option max-file-size 64kB >> >> subvolumes iocache >> >> end-volume >> >> >> >> volume writebehind >> >> type performance/write-behind >> >> option cache-size 4MB >> >> subvolumes quickread >> >> end-volume >> >> >> >> volume statprefetch >> >> type performance/stat-prefetch >> >> subvolumes writebehind >> >> end-volume >> >> >> >> >> >> >> >> all works fine and smooth, I can write and read on that volume without any >> problem. >> >> The problem is when the node01 is unavailable, I can't access the volume > via >> mount on the Debian box. This doesn't happen if it is the node02 to be >> unavailable. >> >> I expected the same behavior in the two cases, in this way the node01 >> represents an SPOF, am I wrong ? am I missing something the configuration > ? >> >> >> >> Tnx in advance >> >> Rpberto >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Gluster-users mailing list >> Gluster-users at gluster.org >> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users > > > > > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
