[mythtv-users] Suggestions for a partition structure

[Simon Hobson]

Chris Lewis wrote:
> It has 2x 500GB discs..
> So what would you do and why?

OK, this is what I did have until recently :
2 disks. Small /boot partition on each. mirrored with md - which means the system can boot from either disk if one fails. A "neat trick" here is that with these two partitions mirrored, you can read the raw partition so the system is actually capable of bootstrapping from one or other raw partition until the bootloader has loaded all the stuff it needs. Once the ernel has loaded, with it's initrd, then it has all the md stuff ready and carries on using the mirrored pair.
Note: I've since read that Grub natively understands md arrays - so this neat trick might not actually be needed any more.

Then I have another partition on each drive, again mirrored with md, for / (root). I prefere (in general) not to have root on LVM as until recently some of the live/recover disks didn't easily handle this - making recover operations harder. Again, this is something that's getting easier and many live/recover disks now support md and lvm - some of my systems these days do have root on LVM which makes it easily resizable.

Then a chunk, again md mirrored, for an LVM volume. Out of this, I run /var (I **ALWAYS** put /var on a separate filesystem for reasons others have mentioned - it **IS** something I've experienced and it's not pretty if you fill your root filesystem). Some swap is also out of this lvm volume - though if your system is adequately specced, you shoudl rearely, if ever, be using swap.

These rest of each disk is then a raw Linux partition (no raid, no LVM) with the filesystem on each (or rather, a directory on each) configured as a storage directory in Myth. Configure Myth to use the combination (balance both I/O and Free Space) method IIRC.


So this is what I *DID* have - so what's wrong with it.
As pointed out, it means that database operations use both drives, which may also both be in use for recording/playback/transcode/etc. I got to the point where there was a quite noticeable stutter/pause in playback when the system did a reschedule (ie start and end of each recording). Not so bad that it caused a dropout in recordings (normally), but certainly affected playback. If bad (several recordings in progress and/or starting/finishing at the same time), the pause could be several seconds.
Tuning the database made a big improvement - but did not completely eliminate this.

eBuyer had a promo on recently and had 64G SSDs for £30. I now have my OS (and database) on the SSD, so the drives are only used for recordings etc now.
Based on my experience - when people say not to put your recordinis and OS/database on the same drive(s), that is good advice.


There are other options you can consider of course.
One is to put your OS etc on just one drive, and periodically copy it to the other drive (rsync is good for this). It means one of your recording drives is used only for recordings - which will reduce the problems mentioned. But if the OS drive fails, so does your system. If you know your way around the command line, recovery isn't too hard as you have a recent copy - all you'd lose would be database updates (recorded programs, deleted programs, and any changes to recording rules) since you last backup.
This may well be an acceptable compromise - after all, it's only TV ;) For a single bloke this is probably OK, but if there's a WAF to consider, then it might not be an acceptable risk.


Other factors to consider include what the distro of choice installer allows. From memory, last time I installed Mythbuntu (whichever version has Myth 0.24.2 on it) on my frontend I found it didn't support raid or lvm ! Luckily when I partitioned the drive I'd left some spare partitions to allow for experimentation.