[mythtv-users] video artifacts on recordings: could building a raid be the cause?

Mike Hodson mystica at gmail.com
Wed Dec 27 10:20:47 UTC 2017

On Wed, Dec 27, 2017 at 4:48 AM, UB40D <ub40dd at googlemail.com> wrote:

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

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.

> 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.
> Could this be due to the fact that the rai

> d array is being built in the background? I originally didn't think it
> would, given that
> - the machine usually copes with several simultaneous recordings
> - top says that the md0_raid5 rebuild process only takes between 2% and
> 20% of the cpu

RAID5/6 style RAID, while somewhat CPU-using to calculate parity, is
actually a _huge_ amount of I/O.
Mirror raid is significantly less I/O for each byte of data read/written,
but is of course less space-efficient.

> 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).
> 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 ;-(

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.
It "just handles it" and you can optionally "scrub" at any time to verify

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

Entirely plausible, for reasons of I/O load.
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

For example, if you have 5 disks, you have a pattern of:

Disk1  R R R R W R R R R W R R R R W
Disk2  R R R W R R R R W R R R R W R
Disk3  R R W R R R R W R R R R W R R
Disk4  R W R R R R W R R R R W R R R
Disk5  W R R R R W R R R R W R R R R

CONSTANTLY until the array is sync'd.
Each column is a distinct point in time. 4 disks read, one written, in a
stripe pattern.

> 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.
> Are you recording _to_ the array?

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.

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.

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20171227/8d71c40c/attachment.html>

More information about the mythtv-users mailing list