<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 23, 2019, 10:57 James Abernathy <<a href="mailto:jfabernathy@gmail.com" target="_blank" rel="noreferrer">jfabernathy@gmail.com</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 1/23/19 11:45 AM, Curtis Gedak wrote:<br></blockquote></div></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> When I had both the OS/MythTV/datbase and the recordings on the same<br>
> drive I experienced more frequent failures.<br>
><br></blockquote></div></div><div dir="auto">Curtis, </div><div dir="auto">this is very likely to the raid timeout issue that was mentioned previously in this thread. normally I find when an array and the timeout match and the colonel understands what's going on, then things seem to work a lot better. anecdotally I've also found that ZFS-on-Linux is extremely stable and I trust it to a RAIDZ2 of all of my important data. Mirroring performance is actually quite good with ZFS as well.  </div><div dir="auto"><br></div><div dir="auto">I'm not saying that you or anyone else should switch to it, only that it's worked well for me as I've tried it over the past five years.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> One other important thing is to reduce the writes to the disk devices by<br>
> adding "noatime,nodiratime" to the /etc/fstab mounts.<br>
><br></blockquote></div></div><div dir="auto">this bit of information is partially outdated due to the fact that current drives can survive so many writes due to the fact that they are much larger than the individual write itself, as well as the current default mode of 'relative atime' or specific mode of 'relatime' in place of the 'noatime,nodiratime' in your example.  the difference is that this mode only will update when a file was last accessed once per day and is currently the default if I remember correctly. I would suggest using this mode simply to know once per day granularity of when the file was accessed which is really not many more writes.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br>
I'm thinking about trying to eliminate as many variable as I can. I have <br>
a spare PC. It's  Sandy Bridge (2nd Generation) Core i7 with 8GB RAM. It <br>
has a mixture of 3GB and 6GB SATA ports. I'm now trying to figure out <br>
the best way to proceed.  If I had a lot of extra drives I could just <br>
build a new mythtv backend with the same drive setup I have today and <br>
then once it's up, use the LAN to copy over the database and recordings.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">James, </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div><div dir="auto">If you're going to be using any SSDs, put those on the 6-gigabit ports. The spinning disks can use whatever remaining ports exist.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But could I just build the system with a boot SSD with Ubuntu 18.04 <br>
server and mythtv, then install my existing drives and add them to a set <br>
of RAID Mirrors like I have now.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div><div dir="auto">This is actually a really good way to proceed if you just want to move the current RAID you have along with building a new OS on an SSD.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The unknown part is how to take an old mirror from one system and mount <br>
it in the new system without loosing the data. I've only created empty <br>
RAIDs or replaced a failed drive and added it back in to the mirror.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div><div dir="auto">Using an existing RAID on a new system is actually quite easy; once you boot it you should be able to do a number of different tests to find out what the system sees the raid volume as, and then add it to fstab.</div><div dir="auto"><br></div><div dir="auto">My favorite is using the 'blkid' command, because it will show every block device - disk, partition, raid, filesystem, etc - that the system sees, and hopefully there should be enough useful information given for you to identify individual disks as well as combined raid sets from device mapper.</div><div dir="auto">You could also look at the output of dmesg which I think also exists in systemctl logs as well as boot.log depending on your setup, from boot up to see what the kernel itself displays as all the enumerated hardware.</div><div dir="auto"><br></div><div dir="auto">Hope this helps,</div><div dir="auto"><br></div><div dir="auto">Mike</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div></div>