Cache Directories plugin 

 

Can somebody explain to me (in dumbed down terms) how the Cache Directories plugin actually works?  

 

What i specifically don't understand is why it produces so much CPU load (15%-ish overall load, spikes up to 70% on random cpu cores every few seconds) while the system is IDLE for hours with all HDDs spun down.  

What could it possibly be doing that needs so much CPU cycles when absolutely nothing is going on?  

 

  

 

With the plugin uninstalled CPU load stays below 2%...  

 

Also, if somebody could point me to some foolproof settings so it actually keeps the disks spun down, that would be nice because i can't seem to get it to even do its intended job right. Disks are still spinning up, just looking at folders in Windows Explorer, without even opening anything.  

 

Thanks.

It's just buggy.  Stop it and restart it and the CPU usage will be fine again.  Or just stop using it, as I did.  I can't be bothered to babysit it and restart it all the time.

19 hours ago, ZeroBANG said:

Disks are still spinning up, just looking at folders in Windows Explorer, without even opening anything.  

Do you have a details/preview pane open in Windows Explorer?  Windows might be opening files, even if you're not.

Likely a dumb question, but can somebody explain the Low temperature threshold vs High temperature threshold in he Fan Auto Control plugin? 

Will the Dynamix System Statistics plugin be updated to match Unraid 6.7/6.8 iconography?

 

4 minutes ago, Dazog said:

Will the Dynamix System Statistics plugin be updated to match Unraid 6.7/6.8 iconography?

 

Huh?

   

 

Now, dynamix cache dirs to be upgraded to the new icons would be welcome.

5 hours ago, Squid said:

Huh?

   

 

Now, dynamix cache dirs to be upgraded to the new icons would be welcome.

System stats/disk stats pages still have old win 98 icons from unraid of old

Edited October 12, 20196 yr by Dazog

Hi, I was wondering if someone could help me troubleshoot an error I'm getting on my two Unraid boxes with the Trim plugin. I'm getting this error on both boxes (the device is different between the two, but the error is the same):

 

DATE kernel: BTRFS warning (device dm-4): failed to trim 1 device(s), last error -121

I have tried to re-install the plugin, but it continues to throw this error. I was wondering if there's a way I can run the trim command manually with more verbose output so I can troubleshoot what error it's running into.

 

I have Intel SSDs in the cache drive formatted as BTRFS.

While it would be ideal if trim were working, it isn't really an issue worth worrying about here for this usage.  Even if you're not using the default of "moving" your cached files every night, I wouldn't worry about it.  Unless you've got pretty old SSDs, they're rather proactive now about doing their own garbage collection anyway.  It was a lot more important with earlier drives, but these days the housekeeping is taken care of by the drive's firmware even if it isn't getting told to trim now and then.

23 hours ago, _Shorty said:

While it would be ideal if trim were working, it isn't really an issue worth worrying about here for this usage.  Even if you're not using the default of "moving" your cached files every night, I wouldn't worry about it.  Unless you've got pretty old SSDs, they're rather proactive now about doing their own garbage collection anyway.  It was a lot more important with earlier drives, but these days the housekeeping is taken care of by the drive's firmware even if it isn't getting told to trim now and then.

Gotcha, I'll just uninstall the plug-in! Thanks!

Dynamix file integrity .... bunker ... question.

 

Hi ... run this regularly and only recently have had a couple of corrupt files identified within bunker.

The output seems to be corrupt also as i am unable to identify the files using what is logged to the syslog, is this a known issue?

Here's the output from last run ...

 

'

Oct 14 13:14:29 smtower bunker: error: MD5 hash key mismatch, )/BDMV/STREAM/00246.m2ts is corrupted
Oct 14 13:45:34 smtower kernel: print_req_error: I/O error, dev sdb, sector 3444640
Oct 14 19:36:08 smtower bunker: error: MD5 hash key mismatch, nder The Sea (1954)/BDMV/STREAM/00045.m2ts is corrupted
Oct 14 20:00:03 smtower kernel: print_req_error: I/O error, dev sdb, sector 318644224
Oct 14 20:23:13 smtower bunker: error: MD5 hash key mismatch, ) [4K]/BDMV/BACKUP/CLIPINF/00438.clpi is corrupted

'

I know WHICH disk was being accessed but not what is corrupt aside form that one 'rogue' output,  any ideas??

 

Ignore the i/o errors, thats a whole new problem!

Edited October 16, 20196 yr by superloopy1

superloopy1, this has been reported by multiple users.  I'd say 99.999% chance you do not have any corrupt files at all.  The tool isn't working properly.  This thread is over 100 pages long, but just read over the last few pages and you'll see you're not the only one reporting this.

Edited October 16, 20196 yr by _Shorty

Isn't it working?

 

So should i just give up on running file integrity checks altogether?

More than one of us has shared that we have another source of checksums to check against utilizing other checksum tools, and when this plugin has said there is a corrupted file we have checked against our own checksum with another checksum utility to find the file data has not actually changed at all.  The plugin, for whatever reason(s), is returning bad checksum errors when in fact the file and checksum for it has not actually changed.  One idea is that a file has changed and the linux change notification simply didn't trigger for some reason, so the plugin didn't get notificed of a change and consequently didn't update the checksum to reflect the new/changed data.  And then when it is verifying the checksum it currently gets does not match the stored one and it reports a corrupted file.  Unfortunately, with files that haven't actually changed and have been verified via the other checksum utility/utilities to still actually be the same as it was before, this indicates that something is not operating as intended with the plugin.  But if the dev can't reproduce this it makes it difficult to track down and fix, and it is my understanding that this has not been something the dev has seen locally.

System Stats plugin

 

A minor bug, when disk no. >26, it just stop at 26. I suppose relate device letter excedd sdaa , sdbb ..... Thanks

Edited October 19, 20196 yr by Benson

在2019年6月14日上午6：18，Kevek79说：

我对系统温度有疑问。插入。

我正在ASUSTeK COMPUTER INC。ROG STRIX Z370-G主板上运行6.7.0版。

当我尝试检测可用的驱动程序时，如果我是正确的话，我只会得到直接来自CPU的“ coretemp”，但是主板本身却没有任何信息，例如MB Temp，驱动器箱温度或Fanspeeds等。

谁能给我一个提示或链接到资源来解决这个问题？

I have the same problem as you.Have you solved the problem?My Motherboard is ASUS TUF Z370 Plus-Gaming

On 9/24/2019 at 3:23 PM, nuniesmith said:

Hey, just build a new Ryzen server build with the Ryzen 5 3600. I am having issues getting my System Temp working and cannot find any sensors. Has anyone had any luck with this?

did you ever get this resolved? I am having same issue and I am running the latest 6.8 rc4 and still not working

 

6 hours ago, peezy78 said:

did you ever get this resolved? I am having same issue and I am running the latest 6.8 rc4 and still not working

 

This worked for me

 

 

The lastest update 6.8.0-rc4 the temps worked for me but system seems a little unstable so i'm back on the stable for now. 

The 6.8 series seems to have broken the System Temp plugin for my system.  It was working fine with 6.7.

 

Sensors-detect still finds the sensor chip and driver required, the nct6776. 

 

Found `Nuvoton NCT5573D/NCT5577D/NCT6776F Super IO Sensors' Success!
    (address 0x290, driver `nct6775')
 

But it seems the sensors.conf file in the plugin directory isn't being read. as only the coretemp probes are available.

 

 

38 minutes ago, dalben said:

The 6.8 series seems to have broken the System Temp plugin for my system.  It was working fine with 6.7.

I am running 6.8.0-rc3.  The same sensor (nct6776) is present on my board, detected in the plugin and the CPU, MB temps and fan speed (the latter two through the nct6776) are displayed at the bottom of the GUI.  Perhaps there is something different in rc4, but, up to rc3, it appears to be working and not a general issue.

 

Edited October 28, 20196 yr by Hoopster

3 hours ago, Hoopster said:

I am running 6.8.0-rc3.  The same sensor (nct6776) is present on my board, detected in the plugin and the CPU, MB temps and fan speed (the latter two through the nct6776) are displayed at the bottom of the GUI.  Perhaps there is something different in rc4, but, up to rc3, it appears to be working and not a general issue.

Thanks for that. I'll roll back to rc3 and see if that makes a difference. 

 

UPDATE:

OK, something is amiss but I have no idea where to start looking:

 

sensors-detect output:

Driver `nct6775':
  * ISA bus, address 0x290
    Chip `Nuvoton NCT5573D/NCT5577D/NCT6776F Super IO Sensors' (confidence: 9)

Driver `coretemp':
  * Chip `Intel digital thermal sensor' (confidence: 9)

sensors output:

root@tdm:~# sensors
acpitz-acpi-0
Adapter: ACPI interface
temp1:        +27.8°C  (crit = +99.0°C)
MB Temp:      +29.8°C  (crit = +99.0°C)

coretemp-isa-0000
Adapter: ISA adapter
CPU Temp:     +39.0°C  (high = +80.0°C, crit = +98.0°C)
Core 0:       +37.0°C  (high = +80.0°C, crit = +98.0°C)
Core 1:       +35.0°C  (high = +80.0°C, crit = +98.0°C)
Core 2:       +39.0°C  (high = +80.0°C, crit = +98.0°C)
Core 3:       +36.0°C  (high = +80.0°C, crit = +98.0°C)

modprobe coretemp nct6775 is my go file and I've run it a couple more times. with no change to the discrepancy between sensors-detect and sensors

Edited October 28, 20196 yr by dalben

OK, fixed now.  In a moment of spring cleaning I stripped back a lot of old files and stuff from my flash drive.  It dropped in the default syslinux.cfg file.  That in turn had over written the change I made to make the nct6775 driver available:

 

append initrd=/bzroot acpi_enforce_resources=lax

46 minutes ago, dalben said:

OK, fixed now. 

I am glad it is working for you.  Perhaps your edits are necessary on your board, but, I don't do anything in the go file or syslinux.cfg related to the sensors.  

 

Again, your system may require that and the fact that all is working is what is important not how you got there.

I have made an update to "Dynamix System Temp".

It will not overwrite the sensors-detect file included in Unraid 6.8.

After updating the plugin, you will need to reboot the system in order to restore the sensors-detect file of Unraid 6.8.

In addition driver detection is made a background process and the well-known Unraid spinner is displayed while detection takes place.

I have tested and confirmed working, the updated plugin Dynamix System Temp on my test server, which has an AMD Ryzen 3400G processor and ASRock X570M Pro4 motherboard.