<div dir="ltr"><div>Hi,</div><div><br></div>SAS 7200 RPM disks are not that small size at all (same as SATA basically). If I remember right, the reason of switching to SAS here would be Full Duplex with SAS (you can read and write in the same time to them) Â instead of Half Duplex with SATA disks (read or write per one moment only).</div><div class="gmail_extra"><br><div class="gmail_quote">2014-09-23 9:02 GMT+03:00 Chris Knipe <span dir="ltr">&lt;<a href="mailto:savage@savage.za.org" target="_blank">savage@savage.za.org</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
SSD has been considered but is not an option due to cost.  SAS has<br>
been considered but is not a option due to the relatively small sizes<br>
of the drives.  We are *rapidly* growing towards a PB of actual online<br>
storage.<br>
<br>
We are exploring raid controllers with onboard SSD cache which may help.<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Sep 23, 2014 at 7:59 AM, Roman &lt;<a href="mailto:romeo.r@gmail.com">romeo.r@gmail.com</a>&gt; wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt; just a question ...<br>
&gt;<br>
&gt; Would SAS disks be better in situation with lots of seek times using<br>
&gt; GlusterFS?<br>
&gt;<br>
&gt; 2014-09-22 23:03 GMT+03:00 Jeff Darcy &lt;<a href="mailto:jdarcy@redhat.com">jdarcy@redhat.com</a>&gt;:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; &gt; The biggest issue that we are having, is that we are talking about<br>
&gt;&gt; &gt; -billions- of small (max 5MB) files. Seek times are killing us<br>
&gt;&gt; &gt; completely from what we can make out. (OS, HW/RAID has been tweaked to<br>
&gt;&gt; &gt; kingdom come and back).<br>
&gt;&gt;<br>
&gt;&gt; This is probably the key point.  It&#39;s unlikely that seek times are going<br>
&gt;&gt; to get better with GlusterFS, unless it&#39;s because the new servers have<br>
&gt;&gt; more memory and disks, but if that&#39;s the case then you might as well<br>
&gt;&gt; just deploy more memory and disks in your existing scheme.  On top of<br>
&gt;&gt; that, using any distributed file system is likely to mean more network<br>
&gt;&gt; round trips, to maintain consistency.  There would be a benefit from<br>
&gt;&gt; letting GlusterFS handle the distribution (and redistribution) of files<br>
&gt;&gt; automatically instead of having to do your own sharding, but that&#39;s not<br>
&gt;&gt; the same as a performance benefit.<br>
&gt;&gt;<br>
&gt;&gt; &gt; I’m not yet too clued up on all the GlusterFS naming, but essentially<br>
&gt;&gt; &gt; if we do go the GlusterFS route, we would like to use non replicated<br>
&gt;&gt; &gt; storage bricks on all the front-end, as well as back-end servers in<br>
&gt;&gt; &gt; order to maximize storage.<br>
&gt;&gt;<br>
&gt;&gt; That&#39;s fine, so long as you recognize that recovering from a failed<br>
&gt;&gt; server becomes more of a manual process, but it&#39;s probably a moot point<br>
&gt;&gt; in light of the seek-time issue mentioned above.  As much as I hate to<br>
&gt;&gt; discourage people from using GlusterFS, it&#39;s even worse to have them be<br>
&gt;&gt; disappointed, or for other users with other needs to be so as we spend<br>
&gt;&gt; time trying to fix the unfixable.<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; Gluster-users mailing list<br>
&gt;&gt; <a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
&gt;&gt; <a href="http://supercolony.gluster.org/mailman/listinfo/gluster-users" target="_blank">http://supercolony.gluster.org/mailman/listinfo/gluster-users</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Best regards,<br>
&gt; Roman.<br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
<br>
Regards,<br>
Chris Knipe<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>Best regards,<br>Roman.
</div>