<div><div dir="auto">hi,</div><div dir="auto">thanks both for the replies</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 10 Sep 2020 at 16:08, Darrell Budic &lt;<a href="mailto:budic@onholyground.com">budic@onholyground.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">I run ZFS on my servers (with additional RAM for that reason) in my replica-3 production cluster. I choose size and ZFS striping of HDDs, with easier compression and ZFS controlled caching using SDDs for my workload (mainly VMs). It performs as expected, but I don’t have the resources to head-to-head it against a bunch of individual bricks for testing. One drawback to large bricks is that it can take longer to heal, in my experience. I also run some smaller volumes on SSDs for VMs with databases and other high-IOPS workloads, and for those I use tuned XFS volumes because I didn’t want compression and did want faster healing.<br>
<br>
With the options you’ve presented, I’d use XFS on single bricks, there’s not much need for the overhead unless you REALLY want ZFS compression, and ZFS if you wanted higher performing volumes, mirrors, or had some cache to take advantage of. Or you knew your workload could take advantage of the things ZFS is good at, like setting specific record sizes tuned to your work load on sub-volumes. But that depends on how you’re planning to consume your storage, as file shares or as disk images. The ultimate way to find out, of course, is to test each configuration and see which gives you the most of what you want :)</blockquote><div dir="auto"><br></div><div dir="auto">yes, zfs (or btrfs ) was for compression but also for the added robustness provided by checksums. I didnt mention btrfs but i’m confortable with btrfs for simple volumes with compression.. but i imagine there isnt a large user base of glusterfs + btrfs.</div><div dir="auto"><br></div><div dir="auto">this is a mostly cold dataset with lots of uncompressed training data for ML.</div><div dir="auto"><br></div><div dir="auto">there is one argument for bit fat internally redundant (zfs) brick which is: </div><div dir="auto"> there is more widespread knowledge on how to manage failed drives on zfs..</div><div dir="auto">one of the inputs i was seeking due to my inexperience with glusterfs is this management side.</div><div dir="auto">i didnt see on the docs how to add spare drives or what happens when a brick dies.. what type of healing exists.. if for example there isnt a replacement drive..</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><br>
<br>
And definitely get a 3rd server in there with at least enough storage to be an arbiter. At the level you’re talking, I’d try and deck it out properly and have 3 active hosts off the bat so you can have a proper redundancy scheme. Split brain more than sucks.</blockquote><div dir="auto"><br></div><div dir="auto">agreed, im aware of split brain. will add additional nodes asap, it is already planned.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><br>
<br>
 -Darrell<br>
<br>
&gt; On Sep 10, 2020, at 1:33 AM, Diego Zuccato &lt;<a href="mailto:diego.zuccato@unibo.it" target="_blank">diego.zuccato@unibo.it</a>&gt; wrote:<br>
&gt; <br>
&gt; Il 09/09/20 15:30, Miguel Mascarenhas Filipe ha scritto:<br>
&gt; <br>
&gt; I&#39;m a noob, but IIUC this is the option giving the best performance:<br>
&gt; <br>
&gt;&gt; 2. 1 brick per drive, Gluster &quot;distributed replicated&quot; volumes, no<br>
&gt;&gt; internal redundancy<br>
&gt; <br>
&gt; Clients can write to both servers in parallel and read scattered (read<br>
&gt; performance using multiple files ~ 16x vs 2x with a single disk per<br>
&gt; host). Moreover it&#39;s easier to extend.<br>
&gt; But why ZFS instead of XFS ? In my experience it&#39;s heavier.<br>
&gt; <br>
&gt; PS: add a third host ASAP, at least for arbiter volumes (replica 3<br>
&gt; arbiter 1). Split brain can be a real pain to fix!<br>
&gt; <br>
&gt; -- <br>
&gt; Diego Zuccato<br>
&gt; DIFA - Dip. di Fisica e Astronomia<br>
&gt; Servizi Informatici<br>
&gt; Alma Mater Studiorum - Università di Bologna<br>
&gt; V.le Berti-Pichat 6/2 - 40127 Bologna - Italy<br>
&gt; tel.: +39 051 20 95786<br>
&gt; ________<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; Community Meeting Calendar:<br>
&gt; <br>
&gt; Schedule -<br>
&gt; Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC<br>
&gt; Bridge: <a href="https://bluejeans.com/441850968" rel="noreferrer" target="_blank">https://bluejeans.com/441850968</a><br>
&gt; <br>
&gt; Gluster-users mailing list<br>
&gt; <a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
&gt; <a href="https://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-users</a><br>
<br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Miguel Mascarenhas Filipe</div>