CS01-HS
-
Posts
479 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by CS01-HS
-
-
Good eye re: hdparm printout, I missed that.
Okay but I'm pretty sure unRAID doesn't call hdparm directly - it issues some other command (smartctl?) that then calls hdparm. That call (and its parameters for UDs) is what I'm after - if you happen to know.
Re: USB spindown, I can bore you with details if you want?
SpoilerWith 6.8.3 where UD spindown was controlled by the UD plugin I noticed the drive never spun down. So I wrote user script to monitor activity and spin it down with an hdparm call when inactive. The only problem was as far as unRAID knew it was still spinning so the status LED was wrong. With 6.9 unRAID took over UD spindown which made spindown work (and my script unnecessary) but LED was still wrong, probably because hdparm returns that error. With 6.9 and your plugin spindown and LED status both work.
-
9 hours ago, doron said:
Was this done with the plugin installed and the debug set as you described above?
Plugin was installed but debug was disabled. I re-enabled it (with touch /tmp/spindownsas-debug) and tested again - same results, no additional printouts:
root@NAS:~# touch /tmp/spindownsas-debug root@NAS:~# sdspin /dev/sdb down /usr/sbin/hdparm -y /dev/sdb SG_IO: bad/missing sense data, sb[]: f0 00 01 00 50 40 00 0a 80 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 root@NAS:~# echo $? 0 root@NAS:~# sdspin /dev/sdb root@NAS:~# echo $? 0 root@NAS:~#9 hours ago, doron said:At any rate, this seems to show that your drive is not really being spun down.
It's a USB drive so I can tell by feel when it's spun down and it is. Spin down worked even without this plugin, problem was unRAID wouldn't detect it. My guess is this wrapper suppresses the error code from "bad/missing sense data" which is fortunate for me but it probably shouldn't.
I still don't know the exact command unRAID calls to spin down Unassigned Devices. Do you? I assume it's smartctl but with what parameters exactly? (This is getting outside the scope of your plugin.)
-
Done. Same results whether the drive is active or already spun down.
root@NAS:~# sdspin /dev/sdb down SG_IO: bad/missing sense data, sb[]: f0 00 01 00 50 40 00 0a 80 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 root@NAS:~# echo $? 0 root@NAS:~# sdspin /dev/sdb root@NAS:~# echo $? 0 -
25 minutes ago, doron said:
What version of Unraid are you running?
v6.9.1
27 minutes ago, doron said:How did you set the debug on? Did you modify the code or use one of the debug triggers?
I changed DEBUG to true in /usr/local/emhttp/plugins/sas-spindown/functions
and ran: touch /tmp/spindownsas-debug
-
Interesting:
I don't have SAS drives but I do have a USB drive (Unassigned Device) with a faulty interface that prevents unRAID from properly detecting idle status - so (a) the webGUI shows it spunup regardless of status and (b) unraid issues it a spindown command every spindown interval.
Faulty interface (sdb is the USB):
root@NAS:~# hdparm -C /dev/sdb /dev/sdb: SG_IO: bad/missing sense data, sb[]: f0 00 01 00 50 40 00 0a 80 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 drive state is: unknownI installed this plugin thinking I'd use the code to write my own wrapper but mysteriously it's solved my problem - the drive's status in the webGUI is accurate and no unnecessary spindown commands.
Thanks?
Debug log in case you're curious:
SpoilerMar 15 12:03:41 NAS emhttpd: read SMART /dev/sdb
Mar 15 12:03:41 NAS SAS Assist v0.85: debug: smartctl wrapper caller is smartctl_type, grandpa is emhttpd, device /dev/sdb, args "-A /dev/sdb"
Mar 15 12:03:44 NAS SAS Assist v0.85: debug: smartctl wrapper caller is timeout, grandpa is sh, device /dev/sdb, args "--nocheck=standby --attributes -d auto /dev/sdb"
Mar 15 12:09:11 NAS SAS Assist v0.85: debug: smartctl wrapper caller is bash, grandpa is sshd, device /dev/sdb, args "--nocheck standby -i /dev/sdb"
Mar 15 12:12:55 NAS SAS Assist v0.85: debug: smartctl wrapper caller is smartctl_type, grandpa is emhttpd, device /dev/sdb, args "-A /dev/sdb"
Mar 15 12:18:42 NAS emhttpd: spinning down /dev/sdb
Mar 15 12:18:54 NAS SAS Assist v0.85: debug: smartctl wrapper caller is timeout, grandpa is sh, device /dev/sdb, args "--nocheck=standby --attributes -d auto /dev/sdb"
Mar 15 12:19:26 NAS SAS Assist v0.85: debug: smartctl wrapper caller is timeout, grandpa is sh, device /dev/sdb, args "--nocheck=standby --attributes -d auto /dev/sdb"
Mar 15 12:19:57 NAS SAS Assist v0.85: debug: smartctl wrapper caller is timeout, grandpa is sh, device /dev/sdb, args "--nocheck=standby --attributes -d auto /dev/sdb"
Mar 15 12:20:29 NAS SAS Assist v0.85: debug: smartctl wrapper caller is timeout, grandpa is sh, device /dev/sdb, args "--nocheck=standby --attributes -d auto /dev/sdb"
-
32 minutes ago, dlandon said:
Feel free to edit the /flash/config/plugins/unassigned.devices/unassigned.devices.cfg file and see if there is something out of order.
Nothing obvious but maybe because I did the fix. I'll wait 'till it happens again and compare. Thanks.
-
5 hours ago, dlandon said:
Post diagnostics.
Attached. Thanks.It's really minor so no need to fix my case, I only posted in case it indicated a general problem that affected more users. (If it's relevant, I think it popped up some time in the last couple/few months.)
-
Strange problem where after every reboot (or maybe array stop/start) my attached USB's partition is visible as an SMB share despite having sharing disabled at the disk and partition level. Enabling then disabling sharing in the partition's settings fixes it. Anyone else seeing this?
-
7 hours ago, JTok said:
why not just use "Number of Backups to Keep" and set it to 1 instead of using "number of days to keep backups"?
Because the lowest allowed value there is 2!
Disabling restrictive validation solved it though, thank you.
-
Thanks for the work on this. No rush at all but I wanted to suggest a (simple?) fix before I forget.
My use case is weekly backups to the array which are then backed up to a versioned system. So I only need one backup on the array at a time. The problem is the lowest number allowed for Number of days to keep backups is 7 (inclusive) which ends up keeping two.
To allow the value I want (1) I run it with this patch with no apparent problems for several months:
root@NAS:~# diff /usr/local/emhttp/plugins/vmbackup/include/javascript/vmbackup.js.orig /usr/local/emhttp/plugins/vmbackup/include/javascript/vmbackup.js 1195c1195 < change_attr("#number_of_days_to_keep_backups", "pattern", "^(0|([7-9]|[1-8][0-9]|9[0-9]|1[0-7][0-9]|180))$"); --- > change_attr("#number_of_days_to_keep_backups", "pattern", "^(0|([1-9]|[1-8][0-9]|9[0-9]|1[0-7][0-9]|180))$"); root@NAS:~# -
With 6.9 on my Asrock j5005 (UHD 605) I'd get occasional lockups not with Emby, as far as I could tell, but with Handbrake GPU encoding and the intel-gpu-telegraf docker. Installing an HDMI dummy plug seems to have fixed it - it hasn't happened since. I don't know if that's specific to my board or more general.
NOTE: I'm using the new modprobe method to load the driver.
-
16 hours ago, david_w said:
However, unraid overwrites the udev folder on boot. So this is not an option.
I don't know enough about the plugin to know if that's the best solution but you can overwrite the rules file on boot by saving your custom version on the flash drive (I created the directory /boot/extras/ for custom scripts) then adding something like the following to your /boot/config/go file:
# Custom autofan cp /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/autofan /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/autofan.orig cp /boot/extras/autofan /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/autofan -
37 minutes ago, limetech said:
Do not use hdparm directly to spindown devices.
Do not use because (a) it won't be reflected in the GUI or (b) it may cause more serious problems like data corruption?
If (b) does it apply to only array disks or pool disks as well?
-
@BurntOC I've only used that procedure once and with a different plugin. I hope I didn't lead you astray.
-
2 hours ago, Roman Melnik said:
The same
I have created an issue in bug tracker: https://github.com/JTok/unraid.vmbackup/issues/25If like me you upgraded to 6.9 before installing the latest version I think you'd be fine - v0.2.1 works for me. I'm pretty sure there's a way to install specific versions manually with the webGUI but I can't remember how.
Edit: I remembered - go to plugins -> Install Plugin then paste the following in the URL field:
https://raw.githubusercontent.com/jtok/unraid.vmbackup/v0.2.1/vmbackup.plg
-
For what it's worth I've been running 6.9-RC2 since it was released and although the latest version of the plugin prevents me from installing it, the version prior has worked consistently in my weekly runs.
-
Thanks, thought maybe I missed something.
I should also mention I set an autostart delay (to give it time to establish the connection.)
-
Using this container (which I've renamed vpn) I create a new network with the following command and route all related containers through it:
docker network create container:vpn
It's straightforward and (from what I can tell) works reliably, no issues with the latest update.
Many seem to use proxies instead - are there advantages to that method?
-
On 2/17/2021 at 12:46 PM, CS01-HS said:
Emby doesn't intelligently manage temporary transcoding files and can fill your drive in some scenarios.
For anyone following my earlier instructions I've switched to using /dev/shm/ as the transcode directory. I think there may be a timing issue where the container tries to access the tmpfs before it's created which obviously caused problems. Referencing a permanent directory (/dev/shm/) avoids that. So far so good.
-
1
-
-
I think a cache drive is optional and if so, no, they can run from the array.
Here are instructions for replacing your cache pool but they may not be current so search to confirm:
-
I haven't tested enough to confirm it's related but some time after installing the GUI plugin my syslog server started logging to syslog-127.0.0.1.log rather than syslog-<my unraid server's IP>. After uninstalling it it's back to normal. Strange.
-
I have no experience with 10K SAS drives but RAID 0 or RAID 5 will be faster than the array which is limited by the speed of a single drive, so you're better off with docker apps in the RAID pool.
I forgot to mention in my other post - no reflashing. You format the pool as BTRFS and set the RAID level with the web GUI (software.)
-
I've run 3 drives in a secondary RAID 5 pool since about beta-25, so far so good.
It shows as protected on the Shares page.
I'd worry about speed with appdata.
Doesn't hurt to try?
*Sometimes it hurts to try.
-
Thanks but I meant a console command (I'm trying to script something.)
[Plugin] Spin Down SAS Drives
in Plugin Support
Posted
sdspin! That's what I was looking for, thank you. I mistakenly assumed that script was specific to your plugin. And I see the plugin helpfully saves the default version so I'll dig in and figure out the difference.