itimpi

As far as I know that is expected behaviour. The parity Check Tuning plugin gives you the option to automatically pause the array operation while mover is running so that mover runs at maximum speed and then resume the array operation when mover completes.

What is the IP you have set for the PC end on the Ethernet port that is directly wired to the Unraid server.

Not clear how everything is set up from a network perceptive? How do you have the rest of the network configured? If your PC is wired directly to Unraid, does the Unraid server have a wired link to a router (and if so what address is that using)?

I wanted to use a <custom> path which would point to a device I mounted via the ‘go’ file and unmounted via the ‘stop’ file. This would have been ideal as it would stay available all the time Unraid was running irrespective of array status.

You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread. It is always a good idea when asking questions to supply your diagnostics so we can see details of your system, how you have things configured, and the current syslog.

I think this is broken at the moment? I could not get it to work.

Your syslog contains: Mar 26 17:15:29 Tower kernel: r8169 0000:03:00.0 eth0: Link is Up - 100Mbps/Full - flow control rx/tx which shows the link is only operating at 100Mbps which explains the throughput figures you are seeing. This can happen if a LAN cable has any of its twisted pairs broken or if any of the ports the cable plugs into have a pin not connection properly as in such a case a 1000Mbps connection silently downgrades itself to 100Mbps. Have you tried with different ports and/or cables? Not sure if router2 only being 100Mbps can affect things as well. Nowadays one expects routers to have 1000Mbps ports or better.

OK - since only the original post contained diagnostics, are you saying that the subsequent syslogs posted are ones created by the syslog server and are not RAM copies? Just asking as it is clearer when posting diagnostics (using the latest Unraid version) as the syslog server version included there gets labelled as syslog-previous.txt when using mirror to flash.

You cannot have 200 as the last byte of the IP address on both the PC and Unraid - they need to be different values. If you used DHCP to get the addresses assigned by your router then that would automatically have given them different values. If you want fixed IP addresses normally best to leave the server and PC set to use DHCP, and then set the fixed addresses for each of them within the router settings.

You should post your system's diagnostics zip file in your next post in this thread to get more informed feedback. It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs. Have you tried doing iperf3 tests between your PC and the Unraid server to check the network speeds being obtained between them? Your symptoms look like what one would expect if the network is only running at 100 Mbps.

The syslog in the diagnostics is the RAM version that starts afresh every time the system is booted. You should enable the syslog server (probably with the option to Mirror to Flash set) to get a syslog that survives a reboot so we can see what leads up to a crash/freeze to see if it shows anything. The mirror to flash option is the easiest to set up (and if used the file is then automatically included in any diagnostics), but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field.

If you want to get this resolved you should post a screenshot of the settings page for the syslog server. Probably something simple that is the reason you are not getting anything.

The syslog you posted does seem to show the network parodically dropping out and then coming back again. This may well be due to something external to Unraid (such as the router or other network components). No reason that is obvious. The syslog in the diagnostics is the RAM version that starts afresh every time the system is booted. You should enable the syslog server (probably with the option to Mirror to Flash set) to get a syslog that survives a reboot so we can see what leads up to a crash or freeze. The mirror to flash option is the easiest to set up (and if used the file is then automatically included in any diagnostics), but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field. BTW: You have the cache_dirs plugin installed and it appears to be set to scan all files/folders. To get the best out of it you should restrict it to shares/folders that you really want it to scan as if it scans too much it cannot keep all the relevant information in RAM to get the benefits it can provide.

The whole idea of Unraid (and RAID in general) is to minimise the chance of loosing data if a drive fails. In terms of backups many people only back up some of their data that they would find to be really painful if it got lost or is irreplaceable. That may not be that large an amount. You may not bother to backup large media files (particularly if you have a way you could replace them if really needed).

Disk1 appears to be where you have your 'system' and 'appdata' shares located and these will be used any time you have the docker subsystem or docker containers running which will be why you get lots of writes to that disk.

It should be 'pool' rather than mentioning 'cache' as that is just a pool of that name.

It is perfectly normal for the drive(s) holding the 'system' share in particular to get regular activity as that is where the docker sub-system constantly has files open all the time it is running (which was what would have kept disk1+parity constantly spun up when that share was on disk1. In addition the same consideration applies to the 'appdata' share any time you have any container running which is configured to use it. In summary from your description you are just seeing the normal activity generated by running docker containers. The whole idea is to keep such writes from going to the main array both for performance reasons and to avoid keeping array disks spun up.

That will be because you had the Parity Check Tuning plugin installed at the time the most recent check was run. The earlier checks which do not show the type of check would have been run before installing the plugin so there is no indication of what type of check they were.

You should post your system's diagnostics zip file in your next post in this thread to get more informed feedback. It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs.

It might be worth posting new diagnostics taken while this is happening.

Das steht in den Fragen und Antworten zur neuen Lizenz.

Soweit ich weiß, gibt es keine zeitliche Begrenzung

Not sure I understand the problem? The Plex data will go to whatever location you configure in the container.

The syslog in the diagnostics is the RAM copy and only shows what happened since the reboot. It could be worth enabling the syslog server to get a log that survives a reboot so we can see what happened prior to the reboot. The mirror to flash option is the easiest to set up, but if you are worried about excessive wear on the flash drive you can put your server’s address into the Remote Server field.

You can get back up and running with all settings intact by doing this followed by this.