<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Xfs on Evan Hoffman</title><link>https://evan.wtf/tags/xfs/</link><description>Recent content in Xfs on Evan Hoffman</description><generator>Hugo</generator><language>en-US</language><copyright>Evan Hoffman</copyright><lastBuildDate>Wed, 02 Jan 2013 16:05:07 +0000</lastBuildDate><atom:link href="https://evan.wtf/tags/xfs/index.xml" rel="self" type="application/rss+xml"/><item><title>XFS write speeds: software RAID 0/5/6 across 45 spindles</title><link>https://evan.wtf/2013/01/02/xfs-write-speeds-software-raid-056-across-45-spindles/</link><pubDate>Wed, 02 Jan 2013 16:05:07 +0000</pubDate><guid>https://evan.wtf/2013/01/02/xfs-write-speeds-software-raid-056-across-45-spindles/</guid><description>&lt;p&gt;We&amp;rsquo;re currently building a new storage server to store low-priority data (tertiary backups, etc). One of the requirements for the project is that it needs to be on cheap storage (as opposed to expensive enterprise SAN/NAS). After some research we decided to build a &lt;a href="http://blog.backblaze.com/2011/07/20/petabytes-on-a-budget-v2-0revealing-more-secrets/"&gt;Backblaze pod&lt;/a&gt;. Backblaze used 3TB Hitachi drives in their system, but the ones they listed in their blog post are discontinued and the reviews for all other 3TB+ drives were terrible, so we went with &lt;a href="http://www.newegg.com/Product/Product.aspx?Item=N82E16822152245"&gt;Samsung ST2000DL004&lt;/a&gt; 2TB 7200 RPM drives. Like Backblaze, we&amp;rsquo;re going with software raid, but I figured a good first step would be to figure out what RAID level we want to use, and if we want to use the mdadm/LVM mish-mosh Backblaze uses, or find something simpler. For my testing I created a RAID6 of all 45 drives and created a single XFS volume (XFS&amp;rsquo;s size limit is ~8 exabytes vs ext4&amp;rsquo;s 16TB). Ext4 may present some performance advantages, but the management overhead is probably not worth it in our case.&lt;/p&gt;</description></item><item><title>Benchmarking disk IO on ext3 vs ext4 vs xfs with fio</title><link>https://evan.wtf/2011/07/22/benchmarking-disk-io-on-ext3-vs-ext4-with-fio/</link><pubDate>Fri, 22 Jul 2011 07:15:05 +0000</pubDate><guid>https://evan.wtf/2011/07/22/benchmarking-disk-io-on-ext3-vs-ext4-with-fio/</guid><description>&lt;p&gt;With the old database phased out, I figured this was a good time to benchmark IO on it before either repurposing it or mothballing it. In &lt;a href="https://evan.wtf/2009/10/27/nilfs-a-file-system-to-make-ssds-scream-in-pain/"&gt;the past&lt;/a&gt; I&amp;rsquo;ve used &lt;code&gt;dd&lt;/code&gt; for elementary sequential read/write testing, but I recently found &lt;a href="http://freshmeat.net/projects/fio/"&gt;fio&lt;/a&gt; which is much more versatile. Apparently developed by FusionIO, fio lets you control concurrency, blocksize and many other parameters and reports lots more data, most notably &lt;a href="http://en.wikipedia.org/wiki/IOPS"&gt;IOPS&lt;/a&gt;.&lt;/p&gt;&#10;&lt;p&gt;I created 4 fio config files, basically the same as the one below, for direct / buffered disk access and sequential / random writes. All have 8k blocksize since that&amp;rsquo;s what Postgres uses by default.&lt;/p&gt;</description></item></channel></rss>