[mythtv-users] Replace backend 3.5 system disk with 2 2.5 raid1?

[Joseph Fry]

On Fri, Sep 26, 2014 at 10:08 AM, Mike Perkins <mikep at randomtraveller.org.uk
> wrote:

> On 26/09/14 14:09, Eric Sharkey wrote:
>
>> On Fri, Sep 26, 2014 at 5:13 AM, Simon Hobson <linux at thehobsons.co.uk>
>> wrote:
>>
>>  It means that *every* write to the system filesystem has to contend with
>>> accesses to all the recording filesystems
>>>
>>
>> The OS drive usage is dominated by reads.
>>
>>  Er, no. Every time that a recording is written to one of the storage
> directories a write is also issued to the database to update the seek table
> for that recording.
>
> That is why it is recommended that the mysql database is not placed on the
> same spindle as any storage directory, because you're automatically
> doubling the head movements - at least.
>
> You're right in that the OS may mostly be reads but there is always the
> database IO to consider. That is usually kept on the same drive as the OS.


Your suggesting that every time you write to the database, the drive stops
what its doing, seeks to the proper location, writes the data, seeks back,
and continues where it left off.

In reality, both the drive itself, and mysql cache the writes... and while
using a recording spindle definitely causes more head movement it's not
nearly as bad as your simple model suggests.

Certainly on a heavy loaded system, it is optimal to put the DB on its own
spindle(s)... but I can tell you from years of experience, on a moderate, 5
tuner (+9 virtual tuners) mythtv system, this is completely unnecessary.  A
simple mythtv system with several recordings, OS, and database all on the
same spindle; I have built several such systems for friends and family.
There is no reason that 3 hard drives, with a 60GB mirrored partition on
each for the OS/DB, can't just as easily do the same, considering that
until I exceed 3 concurrent recordings its typically only writing one
recording to each drive anyway.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20140926/abca0cb1/attachment.html>