JorgeB

Yes, everything written to the array updates parity, so if for example you have 10 data disks parity will end up having 10 times the writes of the data disks.

This is a known issue, there are already multiple bug reports about this, e.g.:

The diagnostics can't help for this, this can:

Try different cables, HBA or PSU.

UDMA CRC errors are a connection problem, and it's fine as long as it doesn't keep increasing, reallocated sector count is not so good, but as long as it's a low number and it remains stable it should be fine, you can acknowledge the current values.

Syslog starts over after every reboot, if it happens again enable this and post that log.

What do you mean by crash then? Usually crash means the server is unresponsive, you can't even get diags, I don't see anything out of the ordinary logged on that syslog.

Did you run memtest?

You should also convert all reiser filesystems to xfs, one of the reasons is that reiserfs is known to become extra slow for big filesystems.

You need to run reiserfsck on disk5.

Please use the existing plugin support thread, also make sure to attach the diagnostics:

It should.

Start by running memtest, then there are some recovery options here.

SMART looks fine, but you can run an extended SMART test to confirm it's good.

You can't do that, the complete procedure must be done in one go, you can start over.

Might not be the issue but one thing you should do is to check the syslog for any errors, some plugins change permissions on install and cause issues with key based SSH login, it happened to me recently, if that is the problem you'll see something like this: Apr 20 18:27:30 Tower15 sshd[15259]: Authentication refused: bad ownership or modes for directory /

Enable this then post that log after a crash.

I do see some nginx issues, but those are outside my wheelhouse: 2021-04-27T11:21:19.000Z,"unraid nginx: 2021/04/27 11:21:19 [error] 11092#11092: *4947 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.0.13, server: , request: ""POST /webGui/include/Boot.php HTTP/1.1"", upstream: ""fastcgi://unix:/var/run/php5-fpm.sock"", host: ""unraid:7000"", referrer: ""http://unraid:7000/Dashboard""" 2021-04-27T11:21:19.000Z,unraid nginx: 2021/04/27 11:21:19 [alert] 11092#11092: *4809 open socket #25 left in connection 10 2021-04-27T11:21:19.000Z,unraid nginx: 2021/04/27 11:21:19 [alert] 11092#11092: *5276 open socket #19 left in connection 9 2021-04-27T11:21:19.000Z,unraid nginx: 2021/04/27 11:21:19 [alert] 11092#11092: *5280 open socket #31 left in connection 13 2021-04-27T11:21:19.000Z,unraid nginx: 2021/04/27 11:21:19 [alert] 11092#11092: *3413 open socket #24 left in connection 8 2021-04-27T11:21:19.000Z,unraid nginx: 2021/04/27 11:21:19 [alert] 11092#11092: *3407 open socket #26 left in connection 18 2021-04-27T11:21:19.000Z,unraid nginx: 2021/04/27 11:21:19 [alert] 11092#11092: aborting Make sure you only have one browser windows open in the GUI, hopefully somebody else has more ideas.

Macvlan call traces are usually the result of having dockers with a custom IP address, more info below. https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/ See also here: https://forums.unraid.net/bug-reports/stable-releases/690691-kernel-panic-due-to-netfilter-nf_nat_setup_info-docker-static-ip-macvlan-r1356/

Enable this then post that log after a crash.

No, just once.

This is how I did it: 1st generate key: ssh-keygen Then copy to other server(s) cat ~/.ssh/id_rsa.pub | ssh root@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys" Replace remote_host with name or IP of dest server.

No, you just need to generate a key and copy it to the other server(s).

This is an LSI/Seagate issue, it can't be fixed by LT, but it might be fixed on a future kernel included in a future Unraid release.