Fireball3

Please check if the Mini-SAS connector is properly seated. Sometimes it looks like but it isn't! Unplug and plug again just to rule that one out.

Thanks for the heads up! Obviously I missed some improvements since I didn't have to jump on every new release as my servers are doing well as they are now. [emoji28] In the meantime I'm increasingly following the principle: "never change a running system" [emoji56] Although, pausing the parity check, is a much anticipated feature that would fit my needs. [emoji847]

Of course you will and that's why the check is done. But it is expected to be only read errors on the drives. That was the reason why I joined unraid in the first place, after I found out that my drives we throwing read errors when lying on the shelf. I remember having had this discussion some years ago in this forum already. If this is a frequent and serious issue, shouldn't there be a better solution how to deal with sync errors? 1. There should be no automatic correction 2. There should be an easy way to inspect the potentially affected data 3. The resync should be limited to the affected area without the need to run another 24h parity check Parity checks put the most stress on the system - at least on mine.

Assuming the system has been properly commissioned and tested before taken into service, it's not reasonable to tear it apart everytime a sync error pops up. At some point one should be able to rely on what it shows - a sync error. That's why the correcting check is on by default and from my understanding there is still no commonly agreed recommendation that this should be done in another way.

Hi, sorry to hijack this topic but is this the commonly agreed procedure? If so, what is the recommended workflow to get everything straightened if there is a sync. error detected (and not corrected)?

This should answer your question: https://forums.unraid.net/topic/47914-controlr-androidios-app-for-unraid/?do=findComment&comment=1014190

Have you tried taping the contacts? There is a detailed description somewhere in the forum. Use the search function please, I'm on tapatalk at the moment. Maybe you have to use another board for the flash procedure.

It's it true that solid state drives are always filled up according to those graphs posted? Will empty space always be shifted in the right side of the graph/drive or will it be more like a sawtooth pattern on a well run in drive where data may have been deleted in random areas of the drive?

Just to make sure I understand it right. The flat line that basically indicates the max. interface throughput is trimmed (empty) space on the SSD?

Those are the features I personally need most. 🤤 Thanks for finally bringing this to life.

I can second this find. I'm playing with a HP NL54 microserver. After installing the plugin it detects the correct sensors. Assignment of sensors Pressing "APPLY" Of course, no sensor data is displayed. After deleting /etc/sensors.d/sensors.conf I can repeat the procedure. If the file is not deleted or modified like below, no chance to get the selection back. Initial sensors.conf root@Tower:~# cat /etc/sensors.d/sensors.conf # sensors chip "k10temp-pci-00c3" label "temp1" "CPU Temp" chip "w83795adg-i2c-1-2f" label "temp2" "MB Temp" chip "w83795adg-i2c-1-2f" label "fan1" "Array Fan" root@Tower:/etc/sensors.d# sensors Error: File /etc/sensors.d/sensors.conf, line 4: Undeclared bus id referenced Error: File /etc/sensors.d/sensors.conf, line 6: Undeclared bus id referenced sensors_init: Can't parse bus name Deleted the sensors.conf and rescan. Sensors were back for selection in the GUI. Note, the K10 sensor disappeared... Pressed APPLY again and they were gone. I change the sensors.conf like this root@Tower:/etc/sensors.d# cat /etc/sensors.d/sensors.conf # sensors chip "w83795adg-i2c-12f" label "temp1" "CPU Temp" chip "w83795adg-i2c-12f" label "temp2" "MB Temp" chip "w83795adg-i2c-12f" label "fan1" "Array Fan" root@Tower:/etc/sensors.d# sensors Error: File /etc/sensors.d/sensors.conf, line 2: Parse error in chip name Error: File /etc/sensors.d/sensors.conf, line 4: Parse error in chip name Error: File /etc/sensors.d/sensors.conf, line 6: Parse error in chip name But the sensors reapear in the GUI. Of course there is no further benefit in having them back for selection, as long as they can't be saved and the temps are not displayed as intended. @bonienl Please let me know how I can contribute further to help debugging this issue. I also noticed this little spelling error in the mouseover.

Is the PCB itself genuine LSI or a rebrand? For LSI you shouldn't need the workaround as for the rebranded cards. Have you tried the toolset I used for the Dell adapters? Should be linked in my signature. Ima posting this from my mobile so can't provide a link right now.

The router will sent the magic packet and wake up the machine if it sees traffic dedicated for the server, but the NIC will have to do its job and listen for it. The router setting just takes over the wake-up task that you would need to perform by hand with a wake up command sent from PC or smartphone. Maybe on those server boards the WOL is done via the management interface? The support should be able to help.

The wake-up can not be performed by the plugin. The feature is called wake-on-lan aka. WOL and it must be configured in the BIOS if you use the on-board NIC. Check the manual of your board. If you use an add-on NIC the issue gets more sophisticated.

Hi, basically the first step should show you the properties of the card. sas2flsh.exe -c 0 -list If your drives show up in unRAID it's also a good sign of success.