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

UB40D ub40dd at googlemail.com
Wed Dec 27 12:09:52 UTC 2017


On 27 December 2017 at 10:20, Mike Hodson <mystica at gmail.com> wrote:

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

I'll bear that in mind for the next time I build a RAID...

At the moment I'm extremely keen to get back to a working myth box before
the hols are over and I no longer have the time to fiddle with this stuff
;-)

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

Indeed. I can sacrifice a fifth drive to the cause, but I can't afford to
have 32 TB mirrored.


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

I don't know what "scrub" means but in the tests I did before committing to
using raid (with 5x 2 GB partitions rather than 5x 8 TB drives), after the
array was built it was able to "just handle" an error. I found that if I
had a 6th drive I could add it in as a spare and it would be brought inline
as and when necessary.
(The thing I found needed more work is being notified that something had
gone wrong.)


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

How can I establish if the sata card or the motherboard impose limits on
the aggregate i/o bandwidth of the drives connected to them? I imagine they
won't support all drives going at full sata speed (if they did, I wouldn't
get any problems).


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

No, as you later noted I had said.


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

correct


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

The motherboard has 2x sata3 and 4x sata2. The PCIe card is 4x sata3. I
never had any illusions that any spinning drive connected to sata-3 would
give me 6 GB/s so I never actually bothered much (and recording a couple of
TV channels at a time doesn't need that anyway). All I did was to stick the
SSD I use to boot on a sata3 slot.


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

That's how it is at the moment, if nothing else because the PCIE card has 4
slots and the raid has 5 drives.


> or splitting the single recording drive off to the PCIE card.
>

That is not the case at the moment. I'm willing to go with your
recommendation, but would you explain why it would be beneficial? I don't
quite get it.


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

Yes, that was my plan anyway, primarily because I think that some of my
el-cheapo 8 TB drives (in deference to the "i" in raid) are rather slow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20171227/5fb8abe9/attachment.html>


More information about the mythtv-users mailing list