ds679

After updating, I received an error from 'Fix Common Problems'

Looks like there is a v5.5.1 'hot fix' just released: https://pi-hole.net/2021/08/04/hotfix-pi-hole-web-v5-5-1-released/#page-content

welp....I figured that 'time would tell' if those changes were successful.....the answer is no. Just received the 'Yellow Warning' with the 115F temp (whereas the actual file shows correct/higher temp) and it is ignoring it. Is it an 'Unassigned Devices' issue? (UPDATE: Nope....as it just happened to my other NVMe drive - yellow warning @ 115 and not the set temp) -dave

And just another follow-up.....after rebooting the GUI page for each drive shows non-corrected values (still the default ones) for all of my NVMe drives....BUT the CLI reading of the files shows the accurate/corrected values. Something seems really broken?

OH....and another weird issue.....my Cache drive entries include their names....while the assigned drive entry does not? Here is my new file: root@Tower4:/boot/config# cat smart-one.cfg [GIGABYTE_GP-ASM2NE6100TTTD_SN202808919XXX] GIGABYTE_GP-ASM2NE6100TTTD_SN202808919XXX_hotTemp="140" GIGABYTE_GP-ASM2NE6100TTTD_SN202808919XXX_maxTemp="158" at0="5" at1="187" at3="197" at4="198" at5="199" [GIGABYTE_GP-ASM2NE6100TTTD_SN202808919XXX] GIGABYTE_GP-ASM2NE6100TTTD_SN202808919XXX_hotTemp="140" GIGABYTE_GP-ASM2NE6100TTTD_SN202808919XXX_maxTemp="158" at0="5" at1="187" at3="197" at4="198" at5="199" [Samsung_SSD_970_EVO_Plus_250GB_S4P3NG0M1159XXX] hotTemp="60" maxTemp="70"

would love to...but when I did - drive spin down after timeout stopped happening...bug report submitted. the original smart-one.cfg seemed to have the correct information (and I have rebooted multiple times since originally changing/correcting the numbers). Will try again - super appreciate the follow-up & response! Ok...when I went back to update/change the numbers (changing them on the line and clicking 'Apply') - it doesn't seem to 'take' - they revert back to the original numbers after the 'Apply' is pressed and screen refreshes! BUT looking at the file from the CLI shows the correct info in the file. I guess it is just waiting for a reboot to show on the screen? And such a weird thing....my 'Cache' drives are showing the temps in 'F' (which is what my system default is) but the 'Dev 1' drive (which is part of 'Unassigned Drives') is showing its information in Celsius? (the correct information with my updated temps - but still different format)....I'm thinking that might be the issue? Thanks again - dave

I have a NVMe that I've set to warn at 140F but continue to get the 'Yellow Warning' that drive is hot (115F). How can I get this warning to respect drive settings? Is this a bug in 6.9.1?

Howdy SimonF.....anything to help out the team!

At the behest of SimonF - here is an issue that I've found (and only corrected by reverting back to 6.9.1) I recently got my first HBA (LSI 9305-16i) with SAS-to-4xSATA cables to be able to add more SATA drives to my rig...the drives are a mixture of: ST8000VN004 ST4000VN008 WDC_WD60EFAX I did the hardware change AND the update to 6.9.2 at the same time and noticed that none of my drives would spin-down automatically (which they had earlier) and thought it was due to the change in hardware. I could force the drives and they would spin-down but not automatically after the set '15 minute' timeout (had 'Enable Spinup Groups' also set to 'No'). After looking at the logs - I would never see spindown requests? Reverted back to 6.9.1 and it automagically worked with no additional changes. HTH and looking forward to 6.9.3? -dave

Ding...ding...winner-winner, chicken dinner back to 6.9.1 and it works.......thanks again

Sorry...maybe I misunderstood (I'm still trying to learn even though have been using UnRaid forever.....I have all my SATA drives connected to the LSI HBA....so, I'm guessing this plugin is not the right one. Thanks for letting me know! Yes...running latest/greatest.....sounds like I'm going to go back to 6.9.1 and test (guess things happened at the same time so I thought it was new hardware) Agreed on the weirdness in logs! Thanks again - dave

have the 4-to-1 SATA to SAS cables (I guess technically that whole thing should be reversed) 15 minutes (in Settings --> Disk Settings --> Default spin down delay as an addendum to above.....Enable Spinup Groups is set to 'No' In system logs (from GUI) -- nothing dmesg - nothing of value to drives and....right, no gray ball...just constant green (with drive temp visible).....is it just tricking me? I think it is a bit disturbing to not see anything in the logs (which is where it checks to issue the spindown....hmm). This used to work on the same system with it was direct to the SATA drives? Thanks again -dave P.S. from other posts (and I'm not sure if it is relevant) but I don't have any SATA drives connected to the on-motherboard SATA ports....only other drives are NVMe on motherboard P.S.S after doing the manual shutdown (by clicking on the green ball) - logs show: Apr 11 19:20:34 Tower4 emhttpd: shcmd (144): /usr/local/sbin/set_ncq sdd 1 Apr 11 19:20:34 Tower4 emhttpd: shcmd (145): echo 128 > /sys/block/sdd/queue/nr_requests Apr 11 19:20:34 Tower4 emhttpd: shcmd (146): /usr/local/sbin/set_ncq sdc 1 Apr 11 19:20:34 Tower4 emhttpd: shcmd (147): echo 128 > /sys/block/sdc/queue/nr_requests Apr 11 19:20:34 Tower4 emhttpd: shcmd (148): /usr/local/sbin/set_ncq sde 1 Apr 11 19:20:34 Tower4 emhttpd: shcmd (149): echo 128 > /sys/block/sde/queue/nr_requests Apr 11 19:20:34 Tower4 emhttpd: shcmd (150): /usr/local/sbin/set_ncq sdf 1 Apr 11 19:20:34 Tower4 emhttpd: shcmd (151): echo 128 > /sys/block/sdf/queue/nr_requests Apr 11 19:20:34 Tower4 emhttpd: shcmd (152): /usr/local/sbin/set_ncq sdg 1 Apr 11 19:20:34 Tower4 emhttpd: shcmd (153): echo 128 > /sys/block/sdg/queue/nr_requests Apr 11 19:20:34 Tower4 emhttpd: shcmd (154): /usr/local/sbin/set_ncq sdb 1 Apr 11 19:20:34 Tower4 emhttpd: shcmd (155): echo 128 > /sys/block/sdb/queue/nr_requests Apr 11 19:20:34 Tower4 kernel: mdcmd (37): set md_num_stripes 2048 Apr 11 19:20:34 Tower4 kernel: mdcmd (38): set md_queue_limit 80 Apr 11 19:20:34 Tower4 kernel: mdcmd (39): set md_sync_limit 5 Apr 11 19:20:34 Tower4 kernel: mdcmd (40): set md_write_method Apr 11 19:20:38 Tower4 emhttpd: shcmd (156): /usr/local/sbin/set_ncq sdd 1 Apr 11 19:20:38 Tower4 emhttpd: shcmd (157): echo 128 > /sys/block/sdd/queue/nr_requests Apr 11 19:20:38 Tower4 emhttpd: shcmd (158): /usr/local/sbin/set_ncq sdc 1 Apr 11 19:20:38 Tower4 emhttpd: shcmd (159): echo 128 > /sys/block/sdc/queue/nr_requests Apr 11 19:20:38 Tower4 emhttpd: shcmd (160): /usr/local/sbin/set_ncq sde 1 Apr 11 19:20:38 Tower4 emhttpd: shcmd (161): echo 128 > /sys/block/sde/queue/nr_requests Apr 11 19:20:38 Tower4 emhttpd: shcmd (162): /usr/local/sbin/set_ncq sdf 1 Apr 11 19:20:38 Tower4 emhttpd: shcmd (163): echo 128 > /sys/block/sdf/queue/nr_requests Apr 11 19:20:38 Tower4 emhttpd: shcmd (164): /usr/local/sbin/set_ncq sdg 1 Apr 11 19:20:38 Tower4 emhttpd: shcmd (165): echo 128 > /sys/block/sdg/queue/nr_requests Apr 11 19:20:38 Tower4 emhttpd: shcmd (166): /usr/local/sbin/set_ncq sdb 1 Apr 11 19:20:38 Tower4 emhttpd: shcmd (167): echo 128 > /sys/block/sdb/queue/nr_requests Apr 11 19:20:38 Tower4 kernel: mdcmd (41): set md_num_stripes 2048 Apr 11 19:20:38 Tower4 kernel: mdcmd (42): set md_queue_limit 80 Apr 11 19:20:38 Tower4 kernel: mdcmd (43): set md_sync_limit 5 Apr 11 19:20:38 Tower4 kernel: mdcmd (44): set md_write_method Apr 11 19:20:57 Tower4 emhttpd: spinning down /dev/sdc Apr 11 19:20:58 Tower4 emhttpd: spinning down /dev/sdf Apr 11 19:20:59 Tower4 emhttpd: spinning down /dev/sdg Apr 11 19:21:01 Tower4 emhttpd: spinning down /dev/sdb Apr 11 19:21:03 Tower4 kernel: mdcmd (45): set md_write_method 0

Am the proud new owner of a LSI 9305-16i (my first adventure into HBAs) - I'm super grateful for your plugin but wanted to know if this is common: works great if I manually spin-down the whole array or individual drives does not work when drives 'time out' and should spin down Is this a config error on my part? Not included with normal functionality? Thanks in advance for any help - dave

Hmmm....ok....so you've got me thinking. I believe that you're saying is to do this: Current Setup: Single M.2 256Gb drive setup as Cache (formatted BTRFS) Future Setup: THREE M.2 drives - existing 256Gb & 1TB & 750GB In that way I could combine the three to make a single 1TB cache?

ahhh....the best laid plans....thanks for the clarification. I guess it would help to add a note to the Wiki/UnRaid docs that while BTRFS doesn't require matched sizes - that the remainder would be wasted in this situation?