<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 7, 2014 at 8:20 AM, Simon Hobson <span dir="ltr"><<a href="mailto:linux@thehobsons.co.uk" target="_blank">linux@thehobsons.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">UB40D <<a href="mailto:ub40dd@googlemail.com">ub40dd@googlemail.com</a>> wrote:<br>
<br>
>> I usually use partition<br>
>> labels now instead of UUIDs to avoid that problem.<br>
><br>
> 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!<br>
<br>
</span>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.<br>
With EXTn type filesystems, use e2label to apply a label, then you can use "LABEL=text" as the device identifier in fstab.<br>
<span class=""><br></span></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I held off for a long time as it looked "daunting". Once you get the hang of it, it's actually fairly simple.<br>
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.<br>
<br>
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.<br>
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.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
</div></div></blockquote></div></div></div>