<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote></div>
Honestly I don't see point to make things more complicated than required.<br>
Adding additional drives because "I could hear the drive thrashing" seems to be little surprising for me.<br></blockquote><div><br></div><div>I didn't actually "add" drives. My system consisted of 3 500 GB drives and a single HDHR recording from QAM... I purchased a HDHR Prime and a 3TB drive, with the intent of moving everything over to a single drive. I tested 5 recordings from my HDHR (was waiting on my cablecard) to the single drive and simply didn't feel comfortable with it due to the obvious thrashing on the drive... and I knew that once I got the Prime up and running it would just get worse. So now my system has 4 drives in it... the 3 500's are used for recordings only... everything else is on the 3TB drive.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Using latter jobqueue to reshuffle recordings....oh my Dear - I understand setup of this was nice brain training during those winter evenings :-)<br>
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.</blockquote>
<div><br></div><div>I did the math, and assuming an HD recording is about 4GB / hour... it's only 17MB/s to write 16 recordings to a single disk... certainly reasonable that a single disk can do it. But with two comflagging jobs running and simultaneous playback of a couple of recordings, the heads are gonna be going nuts. A single SSD doesn't have that issue.</div>
<div><br></div><div>Perhaps my 3 recording drives are overkill... but I am more comfortable with this arrangement.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For the database, you can see a substantial improvement unless your mysql configuration is heavily optimized to eliminate disk reads.<br>
</blockquote></div>
This is interesting.<br>
Pls look here <a href="http://www.gossamer-threads.com/lists/mythtv/users/519664#519664" target="_blank">http://www.gossamer-threads.<u></u>com/lists/mythtv/users/519664#<u></u>519664</a><br>
<br>
Exec summary from above link:<br>
<br>
1.In case of my system build-in-kernel disk buffering is so effective<br>
that even significant speedup of next level storage hierarchy (HDD->SSD)<br>
is totally masked by kernel buffering.<br>
<br>
2.Big enough MySQL caches quite effectively masks speedups in mass-storage.<br>
<br>
3.Recordings rescheduling speed is directly correlated to CPU (going<br>
from Celeron 3,46G to AMD 235E changed reschedule time from 60s to 18s).<br>
<br>
4.For rescheduling speed-up, next, after CPU upgrade & mysql caches, is<br>
moving /tmp to tempfs (noticeable speedup 18s->6s).<br>
<br>
5.Current MythTV system based on quite standard HDD like WD Green is<br>
working really nice even with ATOM CPU. (i.e.86 progs EPG list loads in<br>
aprox 0.2-0.4sec; showing 400+ recordings list is instant (in sense that<br>
there is no time to show loading progress dialog).<br>
<br>
Summarizing:<br>
Speaking in economy: HDD->SSD marginal utility increase is in my case<br>
was ABSOLUTELY not worth of SSD investment.<br>
<br>
Before SSD spending decision I'm strongly recommending:<br>
<br>
-buy more RAM for having huge as possible kernel disk buffers<br>
-move /tmp to tempfs<br>
-allocate 32MB or more for MySQL query cache (and other parameters<br>
accordingly to <a href="http://mysqltuner.pl/" target="_blank">http://mysqltuner.pl/</a>)<br>
<br>
With above it is highly probable that You will get MythTV system where<br>
HDD->SSD upgrade will absolutely not worth the money (and allows You<br>
spent those money elsewhere - with much higher utility).<br>
<br>
YMMV</blockquote><div><br></div><div>On that same thread, others clearly stated that they did see significant performance increases going to SSD. I agree that you may be able to negate most of those increases by ensuring you have enough RAM for a large disk buffer, moving /tmp, and configuring mysql using <a href="http://mysqltuner.pl">mysqltuner.pl</a> and a large query cache. <br>
<br>Regardless... an SSD is a step up from spinning media if cost isn't your primary deciding factor. I still think use as a recording drive is reasonable due to the reduction of access time and latency, and elimination of any impact from fragmentation; if you routinely run your recording drives nearly full, you will get fragmentation regardless of filesystem used, the fact that recordings are so large and your doing multiple recordings at a time only increases the chance of fragmentation.</div>
<div><br></div><div>Is it a worthwhile upgrade when cost is a deciding factor... probably not... which is why I don't have any SSD's in my system.</div></div></div></div>