<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 27, 2017 at 4:48 AM, UB40D <span dir="ltr"><<a href="mailto:ub40dd@googlemail.com" target="_blank">ub40dd@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I rebuilt my myth box after several months of downtime and I decided to bite the bullet and finally build a RAID to store the recordings. This is on ubuntu 16.04, using mdadm.</div></blockquote><div><br></div><div>My personal preference here is ZFSonLinux, which should work fine on Ubuntu 16.04. I'll give some reasons in my further answers inline below.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Several (all?) recordings made yesterday had video artifacts ranging from mild to unwatchable: square patches in areas with motion, frame hiccups, sometimes the bottom 2/3 of the frame without picture.</div><div><br></div><div>Could this be due to the fact that the rai</div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>d array is being built in the background? I originally didn't think it would, given that</div><div>- the machine usually copes with several simultaneous recordings</div><div>- top says that the md0_raid5 rebuild process only takes between 2% and 20% of the cpu</div></div></blockquote><div><br></div><div>RAID5/6 style RAID, while somewhat CPU-using to calculate parity, is actually a _huge_ amount of I/O. </div><div>Mirror raid is significantly less I/O for each byte of data read/written, but is of course less space-efficient. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>On the other hand, test recordings made the day before yesterday, before starting to build the raid array, came out without glitches, which seems to point the finger at the raid and also exclude the hypothesis that I should take a ladder and clean the satellite dish or LNB (also, yesterday was a fine day and it wasn't snowing, so that was not the reason either).</div><div><br></div><div>Building the raid array seems to take 2-3 days (!) so I'm not super-keen to stop it just to check if recordings come out clean. I did have to power-cycle the machine at some point and had to restart building the raid from zero ;-(</div></div></blockquote><div><br></div><div>This is my reason for ZFS: it does _not_ need to "sync" itself upon creation; it does not need to "drop a disk" if one simple read error occurs.</div><div>It "just handles it" and you can optionally "scrub" at any time to verify consistency.</div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Does it seem plausible to anyone that building the raid could be the cause for the video artifacts? The machine is a 4-core i5 with 8 GB RAM. Note that the faulty recordings were made to an independent HDD, not to the raid that was being built.</div></div></blockquote><div><br></div><div>Entirely plausible, for reasons of I/O load.</div><div>Syncing a RAID is _very_ I/O intensive.  You're literally reading every block of every disk, and calculating a new value to be written to the parity-stripe on RAID5.  And with RAID6 you end up writing to 2 parity stripes.  </div><div><br></div><div>For example, if you have 5 disks, you have a pattern of:</div><div><br></div><div>Disk1  R R R R W R R R R W R R R R W </div><div>Disk2  R R R W R R R R W R R R R W R</div><div>Disk3  R R W R R R R W R R R R W R R</div><div>Disk4  R W R R R R W R R R R W R R R</div><div>Disk5  W R R R R W R R R R W R R R R</div><div><br></div><div>CONSTANTLY until the array is sync'd. </div><div>Each column is a distinct point in time. 4 disks read, one written, in a stripe pattern. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I can imagine the problem being disk bandwidth rather than CPU. I have 6 SATA ports on the MB and 4 on a PCI-E card, all connected to drives (and a 700 W PSU). The raid array uses 5 drives and the recording(s) would use a 6th, with the other 4 being idle. There were at times several simultaneous recordings, all going to the same independent drive.</div></div>
<br></blockquote><div>Are you recording _to_ the array? </div><div><br></div><div>If not, then there is likely still some I/O issue if the '6th recording disk' (which sounds like precisely 1 drive is taking all the recordings) is being bandwidth starved due to limitations in the chipset.  I've seen Intel's onboard SATA controllers bandwith-limited to less than 'every disk at once' and have found that most pre-SATA3 generations max out around 500MB/s regardless of what disks or combinations of disks I was accessing.  I had 6 spinning disks on 1 controller, and noticed that I could get ~150-180MB/s sequentially read per disk, but if all at once were accessing i got maybe 500MB/s total inclusive of any overhead. </div><div><br></div><div>If you can, I highly suggest putting the RAID array split between the motherboard and PCIE card, or splitting the single recording drive off to the PCIE card. </div><div><br></div><div>Finally, I would highly suggest to keep using the single disk, or a mirror, to record on, and then only use the RAID5 for long-term storage. Writes to RAID5 are also, very I/O intensive, as its doing the R R R R W cycle for every single block written. </div><div><br></div><div>Mike</div><div><br></div></div></div></div>