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

[Mike Carron]

On 09/26/2014 08:08 AM, Simon Hobson wrote:
> Joseph Fry <joe at thefrys.com> wrote:
>
>> 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.
> Well yes and no.
> "Yes" in that, if you ask the drive to write to one place, it **HAS** to stop writing elsewhere while it seeks, writes, and seeks back again. That's a fairly fundamental limitation of hard drives - unless you get posh ones with two sets of heads and even then that only halves the issue.
> But "no" in that I'm not suggesting that it completely stops writing recordings to disk while the database updates. What actually happens is the thing thrashes while handling multiple streams of writes to different places. **Depending on your system** this may or may not be an issue - but I have certainly seen it in action and I **have** seen damaged recordings because of it.
>
> I am absolutely **NOT** saying that if you share the drive then you'll see lots of problems. Merely that if you do then you reduce the margin between "OK" and "not OK". If you have a lot of spare "capacity" then it's not a problem - but then most of the time you have wasted capacity. If you have a fairly low specced backend (as I had for some time because I couldn't afford to upgrade) then it can make the difference between having to turn off or limit features (eg restricting number of parallel recordings, restricting or not commflagging, restricting transcode jobs) or not. Or put another way, for a given amount of "capacity", keeping the DB in particular off your recordings spindles will allow you to do more without problems.
>
> APart from "problems" there are other issues. When I upgraded my backend (moved OS & DB to SSD primarily) I found responsiveness was vastly improved. Previously I would generally find MythWeb redrew the upcoming recordings screen before a reschedule had finished - so click on "Don't Record", page refreshes, recording still showing until the page is refreshed again. After the upgrade, not only did the page refresh quicker, but it rarely "outpaces" the reschedule. Frontend operations (eg entering the View Recordings menu) also happen quicker.
>
> And of course, if you throw bucketloads of RAM at the system, and tune the DB to use it, then you can really really cut down on DB writes to disk. RAM may or may not be "cheap" depending on your system.
>
> Remember that just because *you* have never seen the problem, it doesn't mean that it doesn't exist.
> I also hold with my view that striping your OS (and by inference, your DB) across all your recording drives is deliberately reducing your margins. If it works for you then fine - but don't just suggest it as an optimal setup because for reasons myself and others have pointed out, while it may work, it's far from optimal.
>
>
***
What is a good way to determine values for tuning the DB? The 
recommendations in the wiki are the same as the defaults in Mythbuntu 14.04.

mike