[mythtv-users] Anyone using SSD for long term storage?

[Warpme]

On 23/07/14 23:26, Joseph Fry wrote:
> On Wed, Jul 23, 2014 at 2:49 PM, jacek burghardt 
> <jaceksburghardt at gmail.com <mailto:jaceksburghardt at gmail.com>> wrote:
>
>     Well do you guys think that using ssd for buffer will imrove mythtv ?
>
>
> Define improve.
>
> Unlike others, I like the idea of using an SSD as a recording drive... 
> because of the lack of access times I could easily sustain all of my 
> recordings and playback on a single drive... i currently use 3 
> spinning recording disks.
.....
> Note, I tried recording 5 HD streams to a single spinning disk, and 
> while it seemed to work, I could hear the drive thrashing.  Spreading 
> the recordings over 3 smaller drives made a huge difference, 
> especially because I have peaked at 8 HD recordings at once.
Honestly I don't see point to make things more complicated than required.
Adding additional drives because "I could hear the drive thrashing" 
seems to be little surprising for me.
Using latter jobqueue to reshuffle recordings....oh my Dear - I 
understand setup of this was nice brain training during those winter 
evenings :-)
MythTV is pretty effective with multiple sustained writes to storage. I 
done many tests with 16xHD in single HDD (WD Green 3TB) - no any 
problem. Sure - HDD LED was constant ON. But HDD role is write/read - so 
as long as IO wait is reasonable - I don't see issue.
>
> For the database, you can see a substantial improvement unless your 
> mysql configuration is heavily optimized to eliminate disk reads.
This is interesting.
Pls look here 
http://www.gossamer-threads.com/lists/mythtv/users/519664#519664

Exec summary from above link:

1.In case of my system build-in-kernel disk buffering is so effective
that even significant speedup of next level storage hierarchy (HDD->SSD)
is totally masked by kernel buffering.

2.Big enough MySQL caches quite effectively masks speedups in mass-storage.

3.Recordings rescheduling speed is directly correlated to CPU (going
from Celeron 3,46G to AMD 235E changed reschedule time from 60s to 18s).

4.For rescheduling speed-up, next, after CPU upgrade & mysql caches, is
moving /tmp to tempfs (noticeable speedup 18s->6s).

5.Current MythTV system based on quite standard HDD like WD Green is
working really nice even with ATOM CPU. (i.e.86 progs EPG list loads in
aprox 0.2-0.4sec; showing 400+ recordings list is instant (in sense that
there is no time to show loading progress dialog).

Summarizing:
Speaking in economy: HDD->SSD marginal utility increase is in my case
was ABSOLUTELY not worth of SSD investment.

Before SSD spending decision I'm strongly recommending:

-buy more RAM for having huge as possible kernel disk buffers
-move /tmp to tempfs
-allocate 32MB or more for MySQL query cache (and other parameters
accordingly to http://mysqltuner.pl/)

With above it is highly probable that You will get MythTV system where
HDD->SSD upgrade will absolutely not worth the money (and allows You
spent those money elsewhere - with much higher utility).

YMMV