Re: [Gluster-users] Glusterfs 2.0 hangs on high load
I have same issue with same config when both nodes are x64. But difference is that, there is no bailout messages in logs. Jasper van Wanrooy - Chatventure wrote: Hi Maris, I regret to hear that. I was also having problems with the stability on 32bit platforms. Possibly you should try it on a 64bit platform. Is that an option? Best Regards Jasper On 28 mei 2009, at 09:36, Maris Ruskulis wrote: Hello! After upgrade to version 2.0, now using 2.0.1, I'm experiencing problems with glusterfs stability. I'm running 2 node setup with cliet side afr, and glusterfsd also is running on same servers. Time to time glusterfs just hangs, i can reproduce this running iozone benchmarking tool. I'm using patched Fuse, but same result is with unpatched. Version : glusterfs 2.0.1 built on May 27 2009 16:04:01 TLA Revision : 5c1d9108c1529a1155963cb1911f8870a674ab5b Starting Time: 2009-05-27 16:38:20 Command line : /usr/sbin/glusterfsd --volfile=/etc/glusterfs/glusterfs-server.vol --pid-file=/var/run/glusterfsd.pid --log-file=/var/log/glusterfsd.log PID : 31971 System name : Linux Nodename : weeber.st-inst.lv Kernel Release : 2.6.28-hardened-r7 Hardware Identifier: i686 Given volfile: +--+ 1: # file: /etc/glusterfs/glusterfs-server.vol 2: volume posix 3: type storage/posix 4: option directory /home/export 5: end-volume 6: 7: volume locks 8: type features/locks 9: option mandatory-locks on 10: subvolumes posix 11: end-volume 12: 13: volume brick 14: type performance/io-threads 15: option autoscaling on 16: subvolumes locks 17: end-volume 18: 19: volume server 20: type protocol/server 21: option transport-type tcp 22: option auth.addr.brick.allow 127.0.0.1,192.168.1.* 23: subvolumes brick 24: end-volume +--+ [2009-05-27 16:38:20] N [glusterfsd.c:1152:main] glusterfs: Successfully started [2009-05-27 16:38:33] N [server-protocol.c:7035:mop_setvolume] server: accepted client from 192.168.1.233:1021 [2009-05-27 16:38:33] N [server-protocol.c:7035:mop_setvolume] server: accepted client from 192.168.1.233:1020 [2009-05-27 16:38:46] N [server-protocol.c:7035:mop_setvolume] server: accepted client from 192.168.1.252:1021 [2009-05-27 16:38:46] N [server-protocol.c:7035:mop_setvolume] server: accepted client from 192.168.1.252:1020 Version : glusterfs 2.0.1 built on May 27 2009 16:04:01 TLA Revision : 5c1d9108c1529a1155963cb1911f8870a674ab5b Starting Time: 2009-05-27 16:38:46 Command line : /usr/sbin/glusterfs -N -f /etc/glusterfs/glusterfs-client.vol /mnt/gluster PID : 32161 System name : Linux Nodename : weeber.st-inst.lv Kernel Release : 2.6.28-hardened-r7 Hardware Identifier: i686 Given volfile: +--+ 1: volume xeon 2: type protocol/client 3: option transport-type tcp 4: option remote-host 192.168.1.233 5: option remote-subvolume brick 6: end-volume 7: 8: volume weeber 9: type protocol/client 10: option transport-type tcp 11: option remote-host 192.168.1.252 12: option remote-subvolume brick 13: end-volume 14: 15: volume replicate 16: type cluster/replicate 17: subvolumes xeon weeber 18: end-volume 20: volume readahead 21: type performance/read-ahead 22: option page-size 128kB 23: option page-count 16 24: option force-atime-update off 25: subvolumes replicate 26: end-volume 27: 28: volume writebehind 29: type performance/write-behind 30: option aggregate-size 1MB 31: option window-size 3MB 32: option flush-behind on 33: option enable-O_SYNC on 34: subvolumes readahead 35: end-volume 36: 37: volume iothreads 38: type performance/io-threads 39: option autoscaling on 40: subvolumes writebehind 41: end-volume 42: 43: 44: 45: #volume bricks 46: #type cluster/distribute 47: #option lookup-unhashed yes 48: #option min-free-disk 20% 49: # subvolumes weeber xeon 50: #end-volume +--+ [2009-05-27 16:38:46] W [xlator.c:555:validate_xlator_volume_options] writebehind: option 'window-size' is deprecated, preferred is 'cache-size', continuing with correction [2009-05-27 16:38:46] W [glusterfsd.c:455:_log_if_option_is_invalid] writebehind: option 'aggregate-size' is not recognized [2009-05-27 16:38:46] W [glusterfsd.c:455:_log_if_option_is_invalid] readahead: option 'page-size' is not recognized [2009-05-27 16:38:46] N [glusterfsd.c:1152:main] glusterfs: Successfully started [2009-05-27 16:38:46] N [client-protocol.c:5557:client_setvolume_cbk] xeon: Connected to 192.168.1.233:6996, attached to remote volume 'brick'. [2009-05-27 16:38:46] N
[Gluster-users] NUFA/replicate setup
Hi, I'm considering using Gluster as the main storage system for a small cluster, but I'm not sure if it fits my needs, or how to configure it to do so. We need an FS that can be expanded incrementally, and is fault tolerant. From reading the docs, I'm hopeful that Gluster with some combination of NUFA and replicate will do what we want, but I'm not really sure how to make it happen. Here are the details: Currently we have ~70 machines, each with a 4x1TB disks in them. We would like to aggregate some, or maybe all, of these into one distributed file system. The DFS would be used for a number of things including: - User home directories - Virtual machine disk images - Large data sets (many TB) The properties that we are looking for are: - Fault tolerance: each piece of data should be replicated, or erasure coded, so that the FS can survive (n) server failures without affecting availability, for some configurable (n). When a server fails, we might not be able to replace/repair it for a while, so the data must be automatically re-replicated when this happens. - Scalable: It must be easy to both add, and remove nodes from the cluster. The cluster will be expanded incrementally, adding 5-10 nodes at a time. Ideally this would be as simple as dropping in the new machine, adding it to a list of storage nodes, and having the FS/ rebalancer daemons take care of the rest. This included adding heterogenous servers with different amounts/types of disks. How close does Gluster come to that kind of plug-and-play? Will data be moved from full nodes to the new one automatically? In addition, it is likely that we will want to remove nodes for extended periods. How easy is it to remove a set of nodes from Gluster without breaking anything. - Handles large files gracefully: If a file is larger than any one server can hold (e.g. many TB), will Gluster automatically stripe it across servers? It looks like it can be configured to do this on a per-mountpoint basis, which is probably fine for us. - Promotes local access: The machines will also be running computation jobs on them, accessing these large data sets, or starting virtual machines from the disk images. Ideally, access would go to the local disk if possible. It looks like NUFA takes care of this, but I don't know how this would interact with replication. Has anyone set up a similar file system with Gluster? What does you config look like? Any advice? Thanks, Jim ___ Gluster-users mailing list Gluster-users@gluster.org http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users
Re: [Gluster-users] Timestamp on replicated files and dirs
- Matthew J. Salerno vagabond_k...@yahoo.com wrote: I'm still unable to find a resolution. Has anyone else come across this? A patch that fixes this is under review. It should be in the repository in a couple of days. Vikas -- Engineer - Z Research http://gluster.com/ ___ Gluster-users mailing list Gluster-users@gluster.org http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users
