Hi Roland, The algorithms are automatically selected based on file size. May I ask what algorithm would you like to select/override to? and why (whats your use case) Thanks, Kamal ----- "Roland Fischer" <roland.fischer@xxxxxxxxxx> wrote: > Hallo, > > i have tried the new version 3 of glusterfs with xen. > > we have 2 gfsserver and 2 xen server. we use client-side-replication > with domUs. > > i need to know if our configuration is good to use with xen domUs: > > server: > # export-domU-images-server_repl > # gfs-01-01 /GFS/domU-images > # gfs-01-02 /GFS/domU-images > > volume posix > type storage/posix > option directory /GFS/domU-images > end-volume > > volume locks > type features/locks > subvolumes posix > end-volume > > volume domU-images > type performance/io-threads > option thread-count 16 # default is 16 > subvolumes locks > end-volume > > volume server > type protocol/server > option transport-type tcp > option auth.addr.domU-images.allow 192.168.11.*,127.0.0.1 > option transport.socket.listen-port 6997 > subvolumes domU-images > end-volume > > and client: > volume gfs-01-01 > type protocol/client > option transport-type tcp > option remote-host gfs-01-01 > option transport.socket.nodelay on > option remote-port 6997 > option remote-subvolume domU-images > option ping-timeout 7 > end-volume > > volume gfs-01-02 > type protocol/client > option transport-type tcp > option remote-host gfs-01-02 > option transport.socket.nodelay on > option remote-port 6997 > option remote-subvolume domU-images > option ping-timeout 7 > end-volume > > volume gfs-replicate > type cluster/replicate > subvolumes gfs-01-01 gfs-01-02 > end-volume > > volume writebehind > type performance/write-behind > option cache-size 16MB > subvolumes gfs-replicate > end-volume > > volume readahead > type performance/read-ahead > option page-count 16 # cache per file = (page-count x page-size) > subvolumes writebehind > end-volume > > volume iocache > type performance/io-cache > option cache-size 1GB > option cache-timeout 1 > subvolumes readahead > end-volume > > > i start a domU and simulate an crash on gfs-01-02 (rcnetwork stop; > sleep > 150; rcnetwork start). domU runs further without any problems. > > Client Log: > [2009-12-10 16:34:16] E > [client-protocol.c:415:client_ping_timer_expired] gfs-01-02: Server > xxx.xxx.xxx.xxx:6997 has not responded in the last 7 seconds, > disconnecting. > [2009-12-10 16:34:16] E [saved-frames.c:165:saved_frames_unwind] > gfs-01-02: forced unwinding frame type(1) op(GETXATTR) > [2009-12-10 16:34:16] E [saved-frames.c:165:saved_frames_unwind] > gfs-01-02: forced unwinding frame type(2) op(PING) > [2009-12-10 16:34:16] N [client-protocol.c:6972:notify] gfs-01-02: > disconnected > [2009-12-10 16:34:38] E [socket.c:760:socket_connect_finish] > gfs-01-02: > connection to xxx.xxx.xxx.xxx:6997 failed (No route to host) > [2009-12-10 16:34:38] E [socket.c:760:socket_connect_finish] > gfs-01-02: > connection to xxx.xxx.xxx.xxx:6997 failed (No route to host) > > network on gfs-01-02 started > > Client Log: > [2009-12-10 16:35:15] N [client-protocol.c:6224:client_setvolume_cbk] > > gfs-01-02: Connected to xxx.xxx.xxx.xxx:6997, attached to remote > volume > 'domU-images'. > [2009-12-10 16:35:18] N [client-protocol.c:6224:client_setvolume_cbk] > > gfs-01-02: Connected to xxx.xxx.xxx.xxx:6997, attached to remote > volume > 'domU-images'. > [2009-12-10 16:35:20] E > [afr-self-heal-common.c:1186:sh_missing_entries_create] gfs-replicate: > > no missing files - /vm_disks/virt-template. proceeding to metadata > check > > everything looks good - sync is started from gfs-01-01 to gfs-01-02 > but > the whole image were transfered. > > if we do a ls -la in domU while the transfer the prompt in domU > disappears. After the sync is ready the prompt in domU appears and we > > can work further. > > my question: is this a normal behavoir? in > http://ftp.gluster.com/pub/gluster/glusterfs/3.0/LATEST/GlusterFS-3.0.0-Release-Notes.pdf > > we have read: > > 2.1) Choice of self-heal algorithms > > During self-heal of file contents, GlusterFS will now dynamically > choose > between two > algorithms based on file size: > > a) "Full" algorithm – this algorithm copies the entire file data in > order to heal the out-ofsync > copy. This algorithm is used when a file has to be created from > scratch on a > server. > > b) "Diff" algorithm – this algorithm compares blocks present on both > servers and copies > only those blocks that are different from the correct copy to the > out-of-sync copy. This > algorithm is used when files have to be re-built partially. > > The “Diff” algorithm is especially beneficial for situations such as > running VM images, > where self-heal of a recovering replicated copy of the image will > occur > much faster because > only the changed blocks need to be synchronized. > > can we change the self-heal algorithmus in config file? > > Thank you very much > > Roland Fischer > > > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxx > http://lists.nongnu.org/mailman/listinfo/gluster-devel
