<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 26, 2014 at 9:09 AM, Eric Sharkey <span dir="ltr">&lt;<a href="mailto:eric@lisaneric.org" target="_blank">eric@lisaneric.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Fri, Sep 26, 2014 at 5:13 AM, Simon Hobson &lt;<a href="mailto:linux@thehobsons.co.uk">linux@thehobsons.co.uk</a>&gt; wrote:<br>
&gt; Joseph Fry &lt;<a href="mailto:joe@thefrys.com">joe@thefrys.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; You do realize that you can raid partitions, not just drives?<br>
&gt;&gt;<br>
&gt;&gt; My system has its OS/database mirrored across the first partition of all 3 of my recording drives.  Essentially I created a 50GB partition on each drive, mirrored them with mdadm, and mounted it as /.  The remainder of the drives is not raided. There are various guides on how to put your /boot on a mirrored array, I have actually tested disconnecting a drive, and other than the missing recordings, the system booted and functioned normally.<br>
&gt;<br>
&gt; You do realise that from the performance PoV that is possibly the worst configuration possible !<br>
<br>
</span>I only use USB disks which I route through a USB -&gt; RS232 -&gt; USB conversion.<br>
<span class=""><br>
&gt; It means that *every* write to the system filesystem has to contend with accesses to all the recording filesystems<br>
<br>
</span>The OS drive usage is dominated by reads.<br>
<span class=""><br>
&gt; - and every read from it has to contend with at least one of the recording filesystems.<br>
<br>
</span>But only if the system is really busy.  With raid 1, the OS doesn&#39;t<br>
issue a read to a drive randomly, it generally picks the least busy<br>
drive (or drives for large reads).  If active recordings are busy<br>
writing to 2/3rds of the disks, OS reads will generally favor the<br>
currently unused mirror.  If the goal is high availability, it&#39;s<br>
really not that bad of a set up.<br></blockquote><div><br></div><div>Thank you for backing me up.</div><div><br></div><div>When I built this I only had 4 sata ports, one of which was connected to an e-sata port so I could do backups to an external hard disk that gets locked up in a firesafe.  That left 3 for recording drives, unless I wanted to waste an entire 750GB drive on the OS.</div><div><br></div><div>As you said, the performance impact is negligible.  Yes, writes to the database are mirrored, so there is an impact to writes... but with three recording drives and only 5 physical tuners, I rarely have more than one recording occurring on any one drive.  Essentially, it would have been wasteful to add spindles for the OS/DB... the overhead for them is quite low.  </div><div><br></div><div>And with a 3 drive mirror, read performance is excellent from the raided drives... and mythtv does a lot more reading than writing on the array.  For example, from the details below you can see that I have read (column 3) about 42x more sectors from the array than I have written (column 5) since my last reboot a couple of days ago.  So the minor hit to writes is more than made up for by distributed reads.</div><div><br></div><div><div>jfry@mythserver:~$ cat /sys/block/md2/stat</div><div>  478611        0 11073882        0   261767        0  7165720        0        0        0        0</div></div><div><br></div><div><br></div><div><br></div></div></div></div>