wgstarks

If you create a share for this on the array you can have both drives assigned and they will be the only ones that spin up (plus parity if you have it installed).

I started receiving error message emails a few weeks ago regarding the original script- error: rsyslog_extra:1 duplicate log entry for /mnt/user/syslog/syslog-10.0.1.1.log error: found error in file rsyslog_extra, skipping Since the error is rather vague it took me a while to determine the cause. More info here. It looks like it was being caused by the fact that I had enabled Syslog Server in 6.7.2 and still had this script enabled. Both were attempting to run the same task. After disabling the original script and rebooting the server the errors have stopped, so I think the issue has been solved. Is there anything else I need to do to fix this?

It looks like this must have been the problem. After disabling this script in the user scripts plugin and rebooting the server I am no longer receiving the error emails.

@bonienl Is it possible that this script you provided is conflicting somehow with my syslog server setup and causing the error I posted in the first post? I created a new share (mnt/user/syslog) for storage of logs for machines using the server and this script seems to be accessing the same share and trying to do the same functions as the system log server (IF I understand it correctly).

I found rsyslog_extra finally. It's at /boot/custom/. /mnt/user/syslog/*.log { su nobody users create 0666 nobody users rotate 5 weekly sharedscripts postrotate /bin/kill -HUP `cat /var/run/rsyslogd.pid 2>/dev/null` 2>/dev/null || true endscript } Not sure why this is generating an error though or why it would send an email to [email protected]?

If you point your containers to /mnt/cache/appdata they will only see what is contained in /mnt/cache/appdata. As soon as mover runs you’ll lose your appdata.

If you set an appdata path of /mnt/cache and then move appdata to the array your appdata won’t be at /mnt/cache anymore and the dockers won’t be able to connect to it.

The email refers to an error in rsyslog_extra, but I can’t find this file at all on my system. From googling it appears that it should be in /etc/rsyslog.d/ but the only thing I see there is a blocklist.

Yes. It was working fine until I shut it down for an extended period to run unRAID tunables. After re-enabling I started getting these errors. Tried rebooting but that didn’t make any difference.

I deleted syslog-10.0.1.1.log along with all the tailed versions (log.1, log.2, etc) and this stopped the error messages for a while but they are back today. It looks like this error is occurring when the system tries to tail the log since entries are still being written to the original log and no previous logs have been created. brunnhilde-diagnostics-20190819-1233.zipbrunnhilde-diagnostics-20190819-1233.zip

Can't do any harm I guess. I'll give it a shot later this week when I can take the server offline.

IF I understand the controller benchmark report correctly it's showing that the controller is installed in an x8 slot right? I could switch slots later this week if there would be some necessity for it.

This one also has a wave form. Looks like the same model. Edit: Not the same but similar.

I think you mean this one- I also uploaded the drive benchmarks to your db.

I'm sure at some point I'll be upgrading all the 4TB drives to 8TB, but at $250US+ each, that probably will only happen as the old drives fail. Was hoping to be able to improve parity check speeds by reconfiguring the system since it seems that my speeds are abnormally low.

Sorry. Realized I had run the wrong benchmark tests. Controller benchmarking shows a variation of 3.3% on the onboard controller (Your controller is not bottlenecking) and a variation of 0.0% on the dell H310 controller (Your controller is not bottlenecking). Not sure what the next step would be to resolve the speed issues?

@jbartlett I installed this docker as you suggested in the UTT thread. No idea how to interpret the results though. sdf is an external drive connected via esata if that matters.

Correction- There are 5 drives connected to the motherboard (including the esata) and 7 connected to the H310.

IIRC, there are 8 drives connected to the H310 which is mounted in the first x8 slot and 4 connected to the motherboard. This does not include cache which is an M.2 SSD mounted in the middle x8 slot. It does include 1 external drive mounted via UD and an estata cable.

I might try moving one drive from the H310 to the motherboard. That would leave 6 on the H310 and 6 on the motherboard.

Yes. It’s why some people use this plugin for stress testing new drives.

With parity protected data everything will involve writes to parity.

Thanks. I ran the test in safe mode with SMB/AFP disabled. Also disabled syslog server. Set mover to run monthly since there is no “disabled” setting for it. Not sure how to eliminate any other internal processes that might be running. Dont have any expanders not shown in the report. The Dell H310 SAS controller is installed in an X8 slot so I don’t think that is limiting speed although it may be that the H310 is slow as you say. I haven’t seen any reports of this though. Same thing is true for the SuperMicro X10SLL-F motherboard. I’ll give Diskspeed a shot, but if it’s really just slow components I don’t think any amount of tweaking will change that.

Do you have the Preclear and Unassigned Devices plugins installed? These will show unassigned drives in the main tab on the webui and a button to start a preclear if that is still what you want. Some people have had issues when trying to preclear too many drives at the same time. I’ve never had any problems with one at a time though.