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

[UB40D]

On 27 December 2017 at 10:23, Jan Ceuleers <jan.ceuleers at gmail.com> wrote:

> Top informs you about the possibility of CPU utilisation being the
> bottleneck. You established that it wasn't.
>

OK


> A more likely bottleneck when building a RAID is that I/O bandwidth is
> the bottleneck, and specifically the seek rate. Rebuilding a RAID
> normally involves sequential reads and writes, but if you do this while
> also accessing the file system the heads constantly have to move back
> and forth between the area being rebuilt and where the file(s) being
> accessed are located.
>

I can't quite understand the second part. What files are being accessed?
There is currently no activity on the raid array other than rebuilding the
5th drive, and as I said the recordings are going to a separate non-raid
drive.


>
> It's too late for that now, but a better way to build an array is to
> assemble it, assuming it's clean (i.e. without a rebuild) and then
> create the filesystem on top of it.


Following a tutorial at

https://www.digitalocean.com/community/tutorials/how-to-create-raid-arrays-with-mdadm-on-ubuntu-16-04
I did
sudo mdadm --create /dev/md0 ...
sudo mkfs.ext4 -F /dev/md0

...and by that time it was already rebuilding. Were you suggesting mdadm
--assemble instead of --create?


> The array is brought into sync when
> each of its blocks is first written, and areas of the array that haven't
> yet been written contain no useful data so it's unimportant that it's
> not in sync.
>
> You can slow rebuilding the array down to a crawl by running something
> like (as root):
>
>         echo 5000 > /proc/sys/dev/raid/speed_limit_max
>
> This will limit the resync speed to 5MB/s and should give you an
> opportunity to assess whether the RAID resync is indeed affecting
> recordings.


Thanks for this one.
I checked the preexisting value before overwriting it and it was 200000.
The expected completion time is now another 4-5 days. I'll let the box
record something else and see if there are any glitches before restoring it
to 200000.


> Set it back to a large number in order to resume at full tilt.
>
> Another approach is to reduce the frequency with which the kernel writes
> your recordings to disk. In other words, to allow it to buffer writes
> for a much longer time. How to do that depends on too many things to go
> into here.
>
> Another thing to check though is whether the power supply in your box
> has enough oomph to power all your disks working hard at the same time.
> If not you should see signs of trouble in dmesg (i.e. read or write
> errors).
>

None of that, fortunately---as I said in the original message I gave it a
700 W PSU.


> > 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.
>
> That's ample.
>

That's what I also thought.


>
> > Note that the faulty recordings were made to an independent HDD, not to
> > the raid that was being built.
>
> How many parallel recordings to this single disk,


I think 2 when the file with all those glitches was recorded.


> what is its type
>

ST5000DM000


> (rotation speed,


5980 rpm


> seek speed)


unknown


> and by which kind of interface is it
> connected to the host?


it has a sata 3 interface but it's attached to a sata 2 port on the
motherboard


> How is this disk powered?


with a sata power connector to the (obviously shared) 700 W PSU


Thanks to both of you for all your help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20171227/222c6a87/attachment.html>