[mythtv-users] Adding an SSD to my MBE -- partitioning question

Tue Feb 14 08:13:22 UTC 2012

On 2/13/12 3:32 PM, Mark J. Small wrote:
> Hi everybody,
>
> I'm getting ready to add a small  (30 GB) SSD to my Master Backend.  Lot's of
> folks say that this will speed things up quite nicely.  I'm just wondering
> about the best way to partition things.
>
> Right now I have two regular HDs.
>
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/sda2              99G   67G   28G  71% /
> /dev/sda1             228M   13M  204M   6% /boot
> /dev/sda4             825G  653G  173G  80% /mnt/store
>
> plus a swap partition
>
> The second has just this:
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/sdb2             625G  454G  171G  73% /mnt/store2
> and about 80 GB of unpartitioned space.
>
> In the root filesystem on sda2, 60 GB of the 67 used reside in /mnt.  /usr and
> /var have about 3 GB each
>
> I was thinking about moving the root file system to the SSD  and turning sda2
> into /mnt.
>
> In previous discussions about SSD's some folks suggested moving /tmp off the
> SSD to keep it from wearing out, especially when there isn't a lot of spare
> RAM to help mysql when the scheduler is run.  I was planning on using some of
> the unpartitioned space on sdb for this.
>
> Does all of this sound reasonable, or am I missing something?
>
> Thanks,
>
> Mark
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>
Mark,

This might be little off-topic, but I believe You will find this as 
another opinion about SSD vs rest of the world.
Inspired by SSD discussions, I was experimenting little with SDD in my 
MythTV system (mythtv backend).
Result were surprising enough that I decide to post them here.

My BE is 880G based mobo with AMD235E CPU, 4G RAM, and base storage on 
2x2TB WD green.
First HDD is OS+DB and hosts HD movies.
Second HDD is /myth volume.
OS is ArchLinux derivative.

All FE are based on ATOM1 and are disk-less PXE booted.
OS is minimyth derivative.

MythTV on tests was v0.25pre-4055-gf9f8b71-dirty-20120111

In my SSD tests I replaced OS+DB drive to SSD (Samsung 830 series, 64G 
model).
SSD was with Ext4, discard, noatime, barriers=off. CHS aligned to 32/32.

General observations:
 From 4G RAM, kernel allocated 2,7G to buffers.
I can expect this level in storage hierarchy (buffers) will be slower 
that RAM but faster than any next in hierarchy storage level (physical 
mass storage).
Also I configured 32M query cache to mysql in hope that DB reads fill be 
mainly from cache. Other parameters were set to mysqltuner.pl suggestions.
I configure /tmp as tempfs in hope that all temp SQL tables will be 
written-read from RAM based mass storage.

After move HDD to SSD:

Results:
Qualitative:
-On FE I practically didn't notice any subjective speed-up.
-Only area where speed-up is seen is mythweb (was instant, with SSD is 
flashy)
-I can definitely say: it is NOT a case where SSD-based system was slow 
like HDD-based one. It is a case where HDD-based system is the same fast 
like SSD (for justification of such statement pls go to end of this post).

Quantitative:
Here are OS boot & scheduling comparisons:

HDD boot:
Jan 11 14:36:54 Startup finished in 3s 54ms 736us (kernel) + 56s 995ms 
395us (userspace) = 1min 50ms 131us.
(I have so long userspace as I add 45sec zoneminder start delay)

HDD scheduling:
2012-01-11 14:53:42.959000 I Scheduled 381 items in 5.7 = 3.44 match + 
2.22 place
2012-01-11 15:46:22.516929 I Scheduled 379 items in 5.8 = 3.50 match + 
2.27 place
2012-01-11 15:51:17.644414 I Scheduled 379 items in 5.9 = 3.55 match + 
2.36 place
2012-01-11 15:56:16.214845 I Scheduled 379 items in 5.9 = 3.55 match + 
2.37 place
2012-01-11 15:57:53.363886 I Scheduled 379 items in 2.4 = 0.00 match + 
2.35 place
2012-01-11 15:59:50.008540 I Scheduled 379 items in 2.4 = 0.00 match + 
2.36 place
2012-01-11 16:07:13.492971 I Scheduled 378 items in 6.0 = 3.74 match + 
2.26 place
2012-01-11 16:11:16.104133 I Scheduled 378 items in 5.9 = 3.73 match + 
2.21 place
2012-01-11 16:16:16.588279 I Scheduled 378 items in 5.7 = 3.55 match + 
2.20 place

SSD boot:
Jan 11 11:57:26 Startup finished in 4s 541ms 296us (kernel) + 52s 835ms 
494us (userspace) = 57s 376ms 790us.

SSD schedulling:
2012-01-11 12:07:04.334242 I Scheduled 383 items in 6.0 = 3.56 match + 
2.39 place
2012-01-11 12:10:03.098568 I Scheduled 382 items in 2.4 = 0.00 match + 
2.36 place
2012-01-11 12:11:15.145393 I Scheduled 382 items in 5.8 = 3.47 match + 
2.36 place
2012-01-11 12:16:16.925119 I Scheduled 382 items in 5.9 = 3.53 match + 
2.35 place
2012-01-11 12:21:16.627705 I Scheduled 382 items in 5.8 = 3.47 match + 
2.33 place
2012-01-11 12:26:14.412831 I Scheduled 382 items in 5.9 = 3.51 match + 
2.35 place
2012-01-11 12:31:16.768138 I Scheduled 382 items in 5.9 = 3.50 match + 
2.39 place
2012-01-11 12:35:31.710289 I Scheduled 382 items in 6.0 = 3.55 match + 
2.44 place

My conclusions:
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).

-br

BTW: I replaced my desktop HDD (Caviar Black 1TB) with this SSD. I'm on 
MAC OSX 10.7.3.
Here SSD plainly SCREAMS.
I.e launching program or restoring it's window are practically 
indistinguishable.