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

[Thomas Mashos]

On Thu, Jul 24, 2014 at 2:16 AM, Warpme <warpme at o2.pl> wrote:
> 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
>
>
> _______________________________________________

While I agree with most of what you said, I do find it a bit humorous
that you're discussing putting the MySQL DB onto an SSD as some kind
of huge investment. We're talking under $50 here. Would RAM be faster?
Yes, but it's also more expensive.

Everything has it's trade-offs I suppose

Thanks,

Thomas Mashos