search for: jburnash

If you haven't seen it already, GlusterFS 3.1.5 is now available at http://www.gluster.org/download/ For those of you currently on the 3.1.x series, we recommend that you upgrade to this latest release. Here are some issues fixed in this release: Bug 2294: Fixed the issue occurred during creating and sharing of volumes with both RDMA and TCP/IP transport type. Bug 2522: Fixed the issue of

"May you live in interesting times" Is this a curse or a blessing? :) I've just tested a 3.1.5 GlusterFS native client against a 3.1.3 storage pool using this volume: Volume Name: pfs-rw1 Type: Distributed-Replicate Status: Started Number of Bricks: 2 x 2 = 4 Transport-type: tcp Bricks: Brick1: jc1letgfs16-pfs1:/export/read-write/g01 Brick2: jc1letgfs13-pfs1:/export/read-write/g01

Howdy, With 3.1.3 the option was added to disable the builtin Gluster NFS. Does that mean that the following scenario should work: 1. Disable Gluster NFS "gluster volume set <VOLUME> nfs.disable on" 2. Restart the gluster servers for good measure 3. On one of the gluster servers, mount the volume using the gluster fuse client: mkdir /export/users # In /etc/fstab add

Hi, we have 4 test machines (gluster01 to gluster04). I've created a replicated volume with the 4 machines. Then on the client machine i've executed: mount -t glusterfs gluster01:/volume01 /mnt/gluster And everything works ok. The main problem occurs in every client machine that I do: umount /mnt/gluster and the mount -t glusterfs gluster01:/volume01 /mnt/gluster The client

Looking for feedback / corrections to my logic for trying to preemptively scan GlusterFS storage for inconsistent file conditions that may prevent access from GlusterFS clients. This is only targeted to the 3.1.x software releases, though may be applicable to earlier and later versions. Steps to troubleshoot client access problems (reorder when a reasonable process has been nailed down) Check