[mythtv-users] Backend with storage group on raid array

[Raymond Wagner]

On 10/15/2011 10:14, Andy Burns wrote:
> However if I'm using chaseplay with a several minutes delay, or
> watching one recording while making another, the playback stutters,
> presumably due to competing access to the disks (even though this is
> only about 2MB/s of reads plus 2MB/s of writes, yet the disks are
> capable of about 330MB/s aggregate reads e.g. during RAID rebuilds

This problem has been discussed before at length on this mailing list 
and other forums.  When MythTV records, it runs a loop that flushes the 
data to the platter roughly once per second per recording.  This 
prevents the buffer from filling too large and getting so that when the 
OS decides to flush on its own, it locks up the system for several 
seconds causing a loss of new capture data.

Each time it flushes, it has to seek to the data location, write the 
data, and then seek to a handful of metadata clusters on the disk to 
record what it just did.  Should your free space be fragmented, and the 
filesystem unable to write the full 2MB or so you have recorded in one 
shot, it will have to seek to a new location and write out the remaining 
data.  If you are recording multiple shows, this process will repeat 
multiple times, resulting in dozens of possible seeks, each eating on 
average 5-10ms.  Reading at playback speed won't be much of an issue, 
unless you have the filesystem mounted to record access times.

Still though, a single 750GB 7200RPM disk should bottom out better than 
50MB/s on its outer edge, and even if half of its time is consumed with 
seeking, you still have far more than sufficient bandwidth left to 
record the 8MB/s of four HD recordings.  The problem is that you're 
using RAID5.  First, since the disks are striped, they all function in 
lock step, meaning they all function as slow as the slowest drive.  
Second, because of the use of parity, it suffers what is called the 
'write hole'.  Any write that is not exactly on stripe boundaries will 
require all the existing data to be read, and new parity to be 
calculated, before it can be written out.  Battery backed hardware RAID 
can fake this, telling the system it has written to disk while 
internally re-ordering stuff for better efficiency, because the battery 
backup ensures any writes that never made it onto the platter can be 
replayed when the system is turned back on.  ZFS can do the same with a 
non-volatile flash drive used as a level 2 cache (L2ARC).  In MDADM, 
you're just screwed, resulting in write performance far less than that 
of a single drive.

> There are a few things I could try ...

You don't want to put recordings on your boot disk, since that will 
merely include MySQL and all its seeking issues into your problems.  You 
don't want to shrink your existing array due to all the hassle that 
entails.  The quickest, easiest, and likely best solution will be to 
simply pick up one or two extra hard drives, connect those 
independently, and record to those instead.  If you've got a couple old 
250GB+ drives laying around, those would work great.  If you want to 
retain the redundancy of your RAID array, add your array as a new 
storage group.  Periodically move the files off your recording drive 
onto the array, and flip the name of the storage group MythTV thinks the 
recordings are in, in the database.