[mythtv-users] Reviving a myth system after hardware failure on /var

[Simon Hobson]

UB40D <ub40dd at googlemail.com> wrote:

> Wait a minute---I'm obviously missing something crucial here. With human-chosen labels, who guarantees uniqueness?

You do !

> What if my old drive and my new restored drive both have a partition with "LABEL=boot", another with "LABEL=root" etc?

You relabel the partitions on the old drive.

It's not as hard as it seems. While setting up the new drive you might use "newboot", "newroot" and so on. Then at switchover you relabel the old "boot" and "root" to "oldboot" and "oldroot" and so on.
It's how I prefer to do things - has the benefits of not using drive identifiers that can change, but is easier to read/write/remember than GUIDs, and the context of this thread, is easier to type when manually repairing a system. Unfortunately, Debian doesn't have the option of automatically configuring Grub to use filesystem labels.

> That's interesting and appealing. I'm only cautious because I'd have to invest the time to learn MD and because I fear it might be much messier to attempt to boot into the system from a rescue disk when something fails.

That's another factor that had me holding off. As long as your boot disk has MD tools on it then it shouldn't be too much of a problem - you just need to remember the magic incantations to have MD do a scan of the drives and start all the arrays to make them appear.

>> One other trick that could be useful for a Myth system is that you can tell it to use one member of a mirrored pair as a "master" - ie tell MD to do most reads from only one member. Thus you could mirror a partition on your "OS drive" with one on a "recording drive" and configure MD so it will treat the latter as a "write only" drive. If your DB is tuned to keep most data in cache then there will be little activity (mostly reads) on the recordings drive.

> Maybe I'm a bit thick but I'm not sure I follow everything here: the recordings drive is marked as write only and as a consequence there will be little activity and mostly reads on it?? Do you mean besides all the writes in the background? Why would there be ANY reads if it's write only?

Sorry, I didn't explain that very well.
On a mirrored array, it's possible to configure MD to bias it's reads to one or other drive - in extreme, do 100% of reads from one drive, so never (or rarely) read from one of the drives at all.

So if you mirror an SSD with a spinning disk, you can configure it so all the reads come from the SSD with practically zero seek time - for reads you get the benefits of the fast random read performance the SSD gives.

Whenever you write something though, it has to be written to both disks - thus the spinning disk is effectively "write only" during normal operations. This can be a bottleneck if you have lots of writes, especially random ones, which is (in part) why I mentioned tuning MySQL carefully to cache it's data in RAM - if it starts writing a lot to disk then performance drops. I think you can configure where MySQL puts temporary files which could be another avenue to look at.

But, if the SSD develops a fault, you have the fault tolerance (albeit with a big performance hit) of falling back to using the mirrored disk.

There's a lot of fun to be had with MD :-)

Just for good measure, I generally only have / and /boot on their own arrays - everything else uses LVM on top of large array.