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

[UB40D]

On Fri, Nov 7, 2014 at 8:20 AM, Simon Hobson <linux at thehobsons.co.uk> wrote:

> UB40D <ub40dd at googlemail.com> wrote:
>
> >> I usually use partition
> >> labels now instead of UUIDs to avoid that problem.
> >
> > I prefer the UUIDs, despite that problem, because if I move the drives
> around physically, or add/remove drives, then I don't have to rewrite the
> fstab for previous partitions that may have changed name. That used to be a
> pain in the pre-UUID days!
>
> If you use filesystem labels then the label stays with the partition
> regardless of what you do. It's not like using device names which depend on
> the order they are connected.
> With EXTn type filesystems, use e2label to apply a label, then you can use
> "LABEL=text" as the device identifier in fstab.
>
>
Wait a minute---I'm obviously missing something crucial here. With
human-chosen labels, who guarantees uniqueness? What if my old drive and my
new restored drive both have a partition with "LABEL=boot", another with
"LABEL=root" etc?


> I held off for a long time as it looked "daunting". Once you get the hang
> of it, it's actually fairly simple.
> You can mix and match what you use. The "traditional" way of doing RAID is
> for the controller to array the whole drives together and present one big
> volume to the OS which is then partitioned. With MD, it's easier to do it
> partition by partition.
>
> I typically make my boot partition as a mirror as that means any single
> member of the set can also be used (read only) if needed although I believe
> GRUB now supports booting from MD arrays. Then my other volumes are
> mirrored, RAID5 or RAID6 depending on the drives I have and the
> requirements.
> As Karl has explained, for each array, each member has to be the same size
> - and MD will warn if the sizes are significantly different when creating
> an array.
>

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.


> 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?


>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20141107/da16ed15/attachment.html>