[mythtv-users] recording drive bottle neck suggestions..

[Raymond Wagner]

sonofzev at iinet.net.au wrote:
> Hi All 
>
> On Sunday night I ended up having a bottle neck as it was the first time I ever
> had 5 recordings going at one (1 HD 4 SD)... the system choked and I couldn't
> watch as the recordings were going (although it appears the recordings ended up
> fine).. The system couldn't seem to playback live TV or even a recording while it
> was being recorded without major stuttering (F1 race so it was important!!)
>
> The cpu seemed fine so I am assuming this is a bottle neck but it's only dual
> core.. do I need more cores for this type of operation?
>
> Ultimately I would like to be able to record 3 HD streams and 3 SD streams
> simultaneously and playback 1 of those streams.. .. but that's just a wish.. not
> a necessity.. 
>
> My MBE recording drive is on an LVM partition on a 4-disk RAID 5 configuration...
> With 300 GB set aside for recording... Itis on XFS with tuning for the RAID
> configuration (large extensts and sunit and swidth)
>   
1 HD channel and 4 SD channels is likely to be well under 40mbps 
(8MB/s), which is well within reasonable limits for a single hard 
drive.  Using RAID5 for recording, you must write to each of those 
drives simultaneously.  While this helps on linear writes, the fact that 
you are flipping between multiple recordings means you're going to waste 
a lot of time seeking to different parts of the array, and the array 
slows to the speed of your slowest drive.  But even still, with that 
little throughput, an array shouldn't have a tough time coping.

The ideal setup is completely independent drives.  Have two or three 
drives not in any array, and stick them all in a storage group.  MythTV 
will automatically load balance between them during recording.  If 
you're concerned about losing recordings during a drive failure, set up 
two storage groups, one with the RAID and one with the spare drives.  
Then just set up a simple user job that moves from one to the other, and 
flips the SG location in the database.  Since you're never going to fill 
these, any spare drives you have laying around should do fine.