Comments on: GlusterFS Linked List Topology https://pthree.org/2013/01/25/glusterfs-linked-list-topology/ Linux. GNU. Freedom. Tue, 31 Oct 2017 18:00:46 +0000 hourly 1 https://wordpress.org/?v=5.0-alpha-42199 By: Lindsay Mathieson https://pthree.org/2013/01/25/glusterfs-linked-list-topology/#comment-266663 Fri, 30 Sep 2016 22:12:01 +0000 http://pthree.org/?p=2991#comment-266663 > GlusterFS should be able to identify the delta, and sync it to the other node, bringing it up-to-date. If not, and neither server has the updated data, then both servers just have old data. The ZFS pool is still fully functional.

I disagree, the sync=disabled sounds very dangerous to me. Suppose you have a number of small files on the volume and write x amount of data to them. Due to the async setting gluster thinks the data is safely on disk when it in fact still resides in the zil.

One server goes down before the data is flushed to disk. Now the files on that server are out of sync with their copies on the other nodes and gluster *doesn't* know this. Your cluster is now inconsistent.

]]>
By: Aaron Toponce https://pthree.org/2013/01/25/glusterfs-linked-list-topology/#comment-227906 Tue, 17 Feb 2015 20:44:05 +0000 http://pthree.org/?p=2991#comment-227906

At the beginning of your article you mention disabling ZFS synchronous writes for GlusterFS but as far as I know this is very dangerous in case the server crashes. Are you sure that it is safe to disable ZFS synchronous writes? What will happen if the server crashes?

ZFS is fully atomic. In the case of "sync=disabled" for ZFS datasets, because of the COW TXGs being atomic in nature, at very worst, you'll end up with old data. You will not end up with corrupted data. Also, GlusterFS is fully synchronous (by default). Because GlusterFS sits on top of ZFS, both GlusterFS peers have the data before sending it to the underlying filesystem (in this case ZFS). So, provided there is an infrastructer-wide power outage (I actually have A/B power Just In Case), and both systems go down, it is possible that one of the systems may have gotten the data where the other did not. Bringing the servers back up, GlusterFS should be able to identify the delta, and sync it to the other node, bringing it up-to-date. If not, and neither server has the updated data, then both servers just have old data. The ZFS pool is still fully functional.

]]>
By: John Naggets https://pthree.org/2013/01/25/glusterfs-linked-list-topology/#comment-227013 Wed, 04 Feb 2015 15:21:14 +0000 http://pthree.org/?p=2991#comment-227013 At the beginning of your article you mention disabling ZFS synchronous writes for GlusterFS but as far as I know this is very dangerous in case the server crashes. Are you sure that it is safe to disable ZFS synchronous writes? What will happen if the server crashes?

]]>
By: Anonymous https://pthree.org/2013/01/25/glusterfs-linked-list-topology/#comment-136892 Sun, 01 Jun 2014 20:44:22 +0000 http://pthree.org/?p=2991#comment-136892 in the linked list scenario there is higher probability of loosing the data if more than 1 node fails.

]]>
By: HippieJoe https://pthree.org/2013/01/25/glusterfs-linked-list-topology/#comment-130459 Tue, 05 Nov 2013 20:22:53 +0000 http://pthree.org/?p=2991#comment-130459 I looked at it a million times, but still missed the vol1 vol2 in the commands. You have two bricks per server. Feel free to delete my posts, and thank you again.

]]>
By: HippieJoe https://pthree.org/2013/01/25/glusterfs-linked-list-topology/#comment-130458 Tue, 05 Nov 2013 20:08:15 +0000 http://pthree.org/?p=2991#comment-130458 Following up; I put a backslash after each brick pair except the last. However, now I get an error that the number of bricks is not a multiple of replica count. I read that this was a requirement in the documentation, but thought the linked approach would get around the issue. Ideas are always welcome. Thank you.

]]>
By: HippieJoe https://pthree.org/2013/01/25/glusterfs-linked-list-topology/#comment-130457 Tue, 05 Nov 2013 19:56:42 +0000 http://pthree.org/?p=2991#comment-130457 Great detail, thank you!

However, I am having an issue with the linked list approach. I have five servers in a glusterfs (3.4.1) cluster, each with 1 brick. I require replication, and due to my odd number of servers, I believe the linked list approach is what I need.

Based on your example, I came up with the below command. All one line when I run it, but broken out here to better show the links:

gluster volume create gfsvol01 replica 2 gfsnode01:/exports/brick1 gfsnode02:/exports/brick1 gfsnode02:/exports/brick1 gfsnode03:/exports/brick1 gfsnode03:/exports/brick1 gfsnode04:/exports/brick1 gfsnode04:/exports/brick1 gfsnode05:/exports/brick1 gfsnode05:/exports/brick1 gfsnode01:/exports/brick1

My issue is that when I run this, I get the error:

"Found duplicate exports gfsnode02:/exports/brick1"

Any help is appreciated, and thank you again!

]]>