doron Posted August 29, 2022 Author Share Posted August 29, 2022 6 hours ago, Dustiebin said: I have been having this issue but with my SATA drives. I have 4 SATA and one SAS all off the same HBA card. Doesn't look like you necessarily have an issue - more like there's i/o activity against your drives. Could be either access to data from a client, or a plugin / docker etc. 6 hours ago, Dustiebin said: This 'app' actually keeps my SAS spun down it is only my SATA's that are getting spun back up with the same SMART trigger. Note the SMART message is not a trigger - it's a response to Unraid seeing (or believing) the drive being spun up. More importantly, note there's a time gap between your spin-down and the SMART messages - a few minutes. That may well reflect normal drive activity. Quote Link to comment
Dustiebin Posted August 30, 2022 Share Posted August 30, 2022 19 hours ago, doron said: Doesn't look like you necessarily have an issue - more like there's i/o activity against your drives. Could be either access to data from a client, or a plugin / docker etc. Note the SMART message is not a trigger - it's a response to Unraid seeing (or believing) the drive being spun up. More importantly, note there's a time gap between your spin-down and the SMART messages - a few minutes. That may well reflect normal drive activity. Thanks for the response. I have turned off all dockers, removed most apps (the fan one, temp one, sleep etc) and still get the issue. I will check the file activity app and see what may be triggering all drives but one to spin back up. Will update with my results. Thanks again Quote Link to comment
JonathanM Posted August 30, 2022 Share Posted August 30, 2022 4 hours ago, Dustiebin said: I have turned off all dockers If the docker menu item is still available, you didn't disable the docker service. Quote Link to comment
cbr600ds2 Posted September 8, 2022 Share Posted September 8, 2022 Just upgraded to 6.10.3 (Yeah, I know I wasn't a fast adopter here) Anyways I'm getting the same issues with SAS HD's (WD's) that look like they're not spinning down. It Seems like the smart read is spinning them up. Anyway to set smart read setting time interval? I'm going to try to shut off dockers this weekend to see if that solves it. No issues w/ SAS not spinning down on 6.9. Sep 6 16:15:21 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdd Sep 6 16:15:35 Skynet emhttpd: spinning down /dev/sde Sep 6 16:15:35 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sde Sep 6 16:15:47 Skynet emhttpd: spinning down /dev/sdg Sep 6 16:15:47 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdg Sep 6 16:16:00 Skynet emhttpd: spinning down /dev/sdi Sep 6 16:16:00 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdi Sep 6 16:16:14 Skynet emhttpd: spinning down /dev/sdl Sep 6 16:16:14 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdl Sep 6 16:16:27 Skynet emhttpd: spinning down /dev/sdn Sep 6 16:16:27 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdn Sep 6 16:16:40 Skynet emhttpd: spinning down /dev/sdt Sep 6 16:16:40 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdt Sep 6 16:16:54 Skynet emhttpd: spinning down /dev/sdu Sep 6 16:16:54 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdu Sep 6 16:17:09 Skynet emhttpd: spinning down /dev/sdy Sep 6 16:17:09 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdy Sep 6 16:17:23 Skynet emhttpd: spinning down /dev/sdz Sep 6 16:17:23 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdz Sep 6 16:18:00 Skynet emhttpd: read SMART /dev/sdc Sep 6 16:18:14 Skynet emhttpd: read SMART /dev/sdd Sep 6 16:18:27 Skynet emhttpd: read SMART /dev/sde Sep 6 16:18:41 Skynet emhttpd: read SMART /dev/sdg Sep 6 16:18:54 Skynet emhttpd: read SMART /dev/sdi Sep 6 16:19:07 Skynet emhttpd: read SMART /dev/sdl Sep 6 16:19:21 Skynet emhttpd: read SMART /dev/sdn Sep 6 16:19:35 Skynet emhttpd: read SMART /dev/sdt Quote Link to comment
doron Posted September 8, 2022 Author Share Posted September 8, 2022 4 hours ago, cbr600ds2 said: Anyways I'm getting the same issues with SAS HD's (WD's) that look like they're not spinning down. The "read SMART" thing is essentially Unraid's response to the drive spinning up, rather than the cause of that spin-up. Note that in your case there seems to be a time gap between the spin-down and "read SMART" messages - like 30 seconds etc. - which usually indicates there's actually some disk activity that spins them up. From the log snippet you provided, it seems as if only some of the drives spin back up, but not all. If that is indeed the case, I'd probably look for a share or folder that lives specifically on these drives, and try to figure out who accesses this share/folder. Just a thought. Quote Link to comment
cbr600ds2 Posted September 9, 2022 Share Posted September 9, 2022 18 hours ago, doron said: The "read SMART" thing is essentially Unraid's response to the drive spinning up, rather than the cause of that spin-up. Note that in your case there seems to be a time gap between the spin-down and "read SMART" messages - like 30 seconds etc. - which usually indicates there's actually some disk activity that spins them up. From the log snippet you provided, it seems as if only some of the drives spin back up, but not all. If that is indeed the case, I'd probably look for a share or folder that lives specifically on these drives, and try to figure out who accesses this share/folder. Just a thought. Here's a weird thing - a few of the drive's has nothing on it. I guess I'll do some checking later Quote Link to comment
cbr600ds2 Posted September 9, 2022 Share Posted September 9, 2022 19 hours ago, doron said: The "read SMART" thing is essentially Unraid's response to the drive spinning up, rather than the cause of that spin-up. Note that in your case there seems to be a time gap between the spin-down and "read SMART" messages - like 30 seconds etc. - which usually indicates there's actually some disk activity that spins them up. From the log snippet you provided, it seems as if only some of the drives spin back up, but not all. If that is indeed the case, I'd probably look for a share or folder that lives specifically on these drives, and try to figure out who accesses this share/folder. Just a thought. OK - with docker turned off - they shut down and then restarted like normal Sep 8 21:39:27 Skynet emhttpd: shcmd (2389481): /etc/rc.d/rc.avahidnsconfd restart Sep 8 21:39:27 Skynet root: Stopping Avahi mDNS/DNS-SD DNS Server Configuration Daemon: stopped Sep 8 21:39:27 Skynet root: Starting Avahi mDNS/DNS-SD DNS Server Configuration Daemon: /usr/sbin/avahi-dnsconfd -D Sep 8 21:39:27 Skynet avahi-dnsconfd[1249]: Successfully connected to Avahi daemon. Sep 8 21:39:27 Skynet emhttpd: shcmd (2389500): /etc/rc.d/rc.docker stop Sep 8 21:39:28 Skynet avahi-daemon[1240]: Server startup complete. Host name is Skynet.local. Local service cookie is 4005251448. Sep 8 21:39:28 Skynet avahi-daemon[1240]: Service "Skynet" (/services/ssh.service) successfully established. Sep 8 21:39:28 Skynet avahi-daemon[1240]: Service "Skynet" (/services/smb.service) successfully established. Sep 8 21:39:28 Skynet avahi-daemon[1240]: Service "Skynet" (/services/sftp-ssh.service) successfully established. Sep 8 21:39:36 Skynet kernel: docker0: port 1(vetha4c41c8) entered disabled state Sep 8 21:39:36 Skynet kernel: vethc1a2034: renamed from eth0 Sep 8 21:39:36 Skynet avahi-daemon[1240]: Interface vetha4c41c8.IPv6 no longer relevant for mDNS. Sep 8 21:39:36 Skynet avahi-daemon[1240]: Leaving mDNS multicast group on interface vetha4c41c8.IPv6 with address fe80::30de:2ff:fe28:5b03. Sep 8 21:39:36 Skynet kernel: docker0: port 1(vetha4c41c8) entered disabled state Sep 8 21:39:36 Skynet kernel: device vetha4c41c8 left promiscuous mode Sep 8 21:39:36 Skynet kernel: docker0: port 1(vetha4c41c8) entered disabled state Sep 8 21:39:36 Skynet avahi-daemon[1240]: Withdrawing address record for fe80::30de:2ff:fe28:5b03 on vetha4c41c8. Sep 8 21:39:36 Skynet kernel: docker0: port 2(veth356cd27) entered disabled state Sep 8 21:39:36 Skynet kernel: veth8dee808: renamed from eth0 Sep 8 21:39:36 Skynet avahi-daemon[1240]: Interface veth356cd27.IPv6 no longer relevant for mDNS. Sep 8 21:39:36 Skynet avahi-daemon[1240]: Leaving mDNS multicast group on interface veth356cd27.IPv6 with address fe80::b021:e2ff:fe8b:ecb7. Sep 8 21:39:36 Skynet kernel: docker0: port 2(veth356cd27) entered disabled state Sep 8 21:39:36 Skynet kernel: device veth356cd27 left promiscuous mode Sep 8 21:39:36 Skynet kernel: docker0: port 2(veth356cd27) entered disabled state Sep 8 21:39:36 Skynet avahi-daemon[1240]: Withdrawing address record for fe80::b021:e2ff:fe8b:ecb7 on veth356cd27. Sep 8 21:39:36 Skynet root: stopping dockerd ... Sep 8 21:39:37 Skynet root: waiting for docker to die ... Sep 8 21:39:38 Skynet avahi-daemon[1240]: Interface docker0.IPv6 no longer relevant for mDNS. Sep 8 21:39:38 Skynet avahi-daemon[1240]: Leaving mDNS multicast group on interface docker0.IPv6 with address fe80::42:95ff:fed6:62b. Sep 8 21:39:38 Skynet avahi-daemon[1240]: Interface docker0.IPv4 no longer relevant for mDNS. Sep 8 21:39:38 Skynet avahi-daemon[1240]: Leaving mDNS multicast group on interface docker0.IPv4 with address 172.17.0.1. Sep 8 21:39:38 Skynet avahi-daemon[1240]: Withdrawing address record for fe80::42:95ff:fed6:62b on docker0. Sep 8 21:39:38 Skynet avahi-daemon[1240]: Withdrawing address record for 172.17.0.1 on docker0. Sep 8 21:39:38 Skynet emhttpd: shcmd (2389502): umount /var/lib/docker Sep 8 21:39:38 Skynet emhttpd: spinning down /dev/sdc Sep 8 21:39:38 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdc Sep 8 21:39:49 Skynet emhttpd: spinning down /dev/sdd Sep 8 21:39:49 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdd Sep 8 21:40:01 Skynet emhttpd: spinning down /dev/sde Sep 8 21:40:01 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sde Sep 8 21:40:14 Skynet emhttpd: spinning down /dev/sdg Sep 8 21:40:14 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdg Sep 8 21:40:26 Skynet emhttpd: spinning down /dev/sdi Sep 8 21:40:26 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdi Sep 8 21:40:38 Skynet nmbd[1207]: [2022/09/08 21:40:38.148858, 0] ../../source3/libsmb/nmblib.c:923(send_udp) Sep 8 21:40:38 Skynet nmbd[1207]: Packet send failed to 172.17.255.255(138) ERRNO=Network is unreachable Sep 8 21:40:40 Skynet emhttpd: spinning down /dev/sdl Sep 8 21:40:40 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdl Sep 8 21:40:53 Skynet emhttpd: spinning down /dev/sdn Sep 8 21:40:53 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdn Sep 8 21:41:06 Skynet emhttpd: spinning down /dev/sdt Sep 8 21:41:06 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdt Sep 8 21:41:18 Skynet emhttpd: spinning down /dev/sdy Sep 8 21:41:18 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdy Sep 8 21:41:32 Skynet emhttpd: spinning down /dev/sdz Sep 8 21:41:32 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdz Sep 8 21:42:22 Skynet emhttpd: read SMART /dev/sdc Sep 8 21:42:36 Skynet emhttpd: read SMART /dev/sdd Sep 8 21:42:49 Skynet emhttpd: read SMART /dev/sde Sep 8 21:43:02 Skynet emhttpd: read SMART /dev/sdg Sep 8 21:43:15 Skynet emhttpd: read SMART /dev/sdi Sep 8 21:43:28 Skynet emhttpd: read SMART /dev/sdl Sep 8 21:43:42 Skynet emhttpd: read SMART /dev/sdn Sep 8 21:43:54 Skynet emhttpd: read SMART /dev/sdt Sep 8 21:44:08 Skynet emhttpd: read SMART /dev/sdy Sep 8 21:44:21 Skynet emhttpd: read SMART /dev/sdz Sep 8 21:44:26 Skynet autofan: Highest disk temp is 104F, adjusting fan speed from: 155 (60% @ 1715rpm) to: 125 (49% @ 1486rpm) Log size: 5000 TextErrorWarningSystemArrayLogin now I'm completely stumped hahaha Quote Link to comment
SimonF Posted September 9, 2022 Share Posted September 9, 2022 (edited) @cbr600ds2 Sep 8 21:44:26 Skynet autofan: Highest disk temp is 104F, adjusting fan speed from: 155 (60% @ 1715rpm) to: 125 (49% @ 1486rpm) I dont think SAS disks are supported by autofan as uses hdparm to check if disks are spundown. Edited September 9, 2022 by SimonF Quote Link to comment
doron Posted September 9, 2022 Author Share Posted September 9, 2022 5 hours ago, cbr600ds2 said: Sep 8 21:44:26 Skynet autofan: Highest disk temp is 104F, adjusting fan speed from: 155 (60% @ 1715rpm) to: 125 (49% @ 1486rpm) (...) now I'm completely stumped hahaha Don't be. Mystery solved. Indeed, Autofan is doing that. It has a bug which causes SAS drives to be spun up every few minutes. Scroll back in this topic for a full discussion. I actually offered a software fix (pull request pending) but the plugin author hasn't responded. Quote Link to comment
Mors Posted September 9, 2022 Share Posted September 9, 2022 On 6/19/2022 at 3:28 AM, doron said: Okay @DavidNguyen, here goes. Again, please note this is not sanctioned by the plugin author and should be considered a hack, just for testing. Also note that I didn't package it back into plugin format, which means that the change will be lost upon reboot. Attached please find the modified script "autofan". Steps to activate: - Place the script in /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/ - chmod 755 autofan - Go to settings, Fan Auto Control, set the function to "Disable", then Apply - (Make sure process "autofan" is not running) - Set function back to "Enable", then Apply You should now have autofan function without offending your SAS drives. Please report success / issues. autofan 13.01 kB · 4 downloads Pardon what I'm sure are some extremely stupid questions, but is this a directory you need to make? I cant seem to find where this is to drop the script into. I dont see anything like this when I browse either my shares, my boot flash drive or my cache disk. I assume the plugins are installed in the config folder of my boot flash drive, but I don't see where this directory would be or would be created (I assume this is all going on the flash drive). furthermore can I use the userscripts plugin to automate having this run everytime I boot up? I see discussion few posts after this "hack" to fix autofan was posted but unfortunately that is greek to me as well. I dont shut down very often, but I like to streamline where I can as I am such a novice I try to get it running in a fire and forget sort of way. Quote Link to comment
SimonF Posted September 9, 2022 Share Posted September 9, 2022 2 hours ago, Mors said: Pardon what I'm sure are some extremely stupid questions, but is this a directory you need to make? I cant seem to find where this is to drop the script into. I dont see anything like this when I browse either my shares, my boot flash drive or my cache disk. I assume the plugins are installed in the config folder of my boot flash drive, but I don't see where this directory would be or would be created (I assume this is all going on the flash drive). furthermore can I use the userscripts plugin to automate having this run everytime I boot up? I see discussion few posts after this "hack" to fix autofan was posted but unfortunately that is greek to me as well. I dont shut down very often, but I like to streamline where I can as I am such a novice I try to get it running in a fire and forget sort of way. You need to put in /usr/local/emhttp/plugins/dynamix.system.autofan/script it should exist if you have autofan installed. you can add cp and a chmod +x to the go file to install at boot or use a user script. Quote Link to comment
Mors Posted September 9, 2022 Share Posted September 9, 2022 3 hours ago, SimonF said: You need to put in /usr/local/emhttp/plugins/dynamix.system.autofan/script it should exist if you have autofan installed. you can add cp and a chmod +x to the go file to install at boot or use a user script. So excuse my ignorance, but I used Krusader to search for the "emhttp" folder, because thats where I can't seem to go any further. Quote Link to comment
cbr600ds2 Posted September 10, 2022 Share Posted September 10, 2022 (edited) 19 hours ago, doron said: Don't be. Mystery solved. Indeed, Autofan is doing that. It has a bug which causes SAS drives to be spun up every few minutes. Scroll back in this topic for a full discussion. I actually offered a software fix (pull request pending) but the plugin author hasn't responded. Ahhh - if I disable autofan then bios will control the fan right? I was reading your script "hack" and I was wondering if I got this right - then I would have to do this everytime I started the array? Can it be added to the userscripts plugin? Edited September 10, 2022 by cbr600ds2 more color Quote Link to comment
SimonF Posted September 10, 2022 Share Posted September 10, 2022 7 hours ago, Mors said: So excuse my ignorance, but I used Krusader to search for the "emhttp" folder, because thats where I can't seem to go any further. I think this will be the root fs of the docker not of the host. you may need to add a mapping for the host root. Open a terminal and run ls /usr/local/emhttp/plugins/dynamix.system.autofan/script Quote Link to comment
SimonF Posted September 10, 2022 Share Posted September 10, 2022 3 hours ago, cbr600ds2 said: Ahhh - if I disable autofan then bios will control the fan right? I was reading your script "hack" and I was wondering if I got this right - then I would have to do this everytime I started the array? Can it be added to the userscripts plugin? You can add as a Userscript or I add in my go changes I am testing. I have a temp dir on the boot drive I add files into cp /boot/temp/file /usr/local/emhttp/plugin/pluginname/.... chmod +x /usr/local/emhttp/plugin/pluginname/.... if it need to be executable. root@computenode:~# cat /boot/config/go #!/bin/bash # Start the Management Utility #sed -i 's/disableLeaveAlert=true/disableLeaveAlert=true -t fontsize=20/' /etc/rc.d/rc.nginx #cp /boot/temp/ArrayOperation.page /usr/local/emhttp/plugins/dynamix/ #cp /boot/temp/parity_list /usr/local/emhttp/plugins/dynamix/nchan/ #cp /boot/temp/mover /usr/local/sbin #chmod +x /usr/local/emhttp/plugins/dynamix/nchan/parity_list #chmod +x /usr/local/sbin/mover #cp /boot/temp/smartctl_type /usr/local/sbin #chmod +x /usr/local/sbin/smartctl_type #cp /boot/temp/sdspin /usr/local/sbin #chmod +x /usr/local/sbin/sdspin #cp /boot/temp/smartctl_test /usr/local/sbin #chmod +x /usr/local/sbin/smartctl_test cp /boot/temp/cli64 /usr/local/sbin chmod +x /usr/local/sbin/cli64 cp /boot/temp/mover.php /tmp chmod +x /tmp/mover.php /usr/local/sbin/emhttp & root@computenode:~# 1 Quote Link to comment
Mors Posted September 10, 2022 Share Posted September 10, 2022 (edited) 10 hours ago, SimonF said: I think this will be the root fs of the docker not of the host. you may need to add a mapping for the host root. Open a terminal and run ls /usr/local/emhttp/plugins/dynamix.system.autofan/script And just to be like confirming I am not an idiot (hopefully), I have both SAS spin down and Auto Fan installed and enabled. You can even see the SAS only not spinning down in my gui. Those are 2 shucked WD drives, they spin down with no issue. and a picture of my log, the only activity I have is the temp being polled. Edited September 10, 2022 by Mors clarification Quote Link to comment
SimonF Posted September 10, 2022 Share Posted September 10, 2022 (edited) 13 minutes ago, Mors said: Do you have autofan plugin installed? Edited September 10, 2022 by SimonF Quote Link to comment
Mors Posted September 10, 2022 Share Posted September 10, 2022 1 minute ago, SimonF said: Do you have autfan plugin installed? I realized 60 seconds after posting you would ask, and I edited with more info. Quote Link to comment
doron Posted September 10, 2022 Author Share Posted September 10, 2022 2 hours ago, Mors said: I realized 60 seconds after posting you would ask, and I edited with more info. See previously in this thread. The autofan plugin has a bug that causes SAS drives (only) to be spun up periodically (every few minutes - basically, the polling interval). Quote Link to comment
Mors Posted September 11, 2022 Share Posted September 11, 2022 (edited) 6 hours ago, doron said: See previously in this thread. The autofan plugin has a bug that causes SAS drives (only) to be spun up periodically (every few minutes - basically, the polling interval). Yea, I am not confused about any of this. You'd have to read my comments to understand what my issue is, but basically I do not have the directory to put the modified script into, to then fix auto fan (or so it appears to me, I am a linux novice). Edited September 11, 2022 by Mors clarification Quote Link to comment
doron Posted September 11, 2022 Author Share Posted September 11, 2022 3 hours ago, Mors said: Yea, I am not confused about any of this. You'd have to read my comments to understand what my issue is, but basically I do not have the directory to put the modified script into, to then fix auto fan (or so it appears to me, I am a linux novice). Sorry for my confusion. Can you post the output of: ls -la /usr/local/emhttp/plugins Quote Link to comment
SimonF Posted September 11, 2022 Share Posted September 11, 2022 (edited) 14 hours ago, Mors said: I realized 60 seconds after posting you would ask, and I edited with more info. Sorry missed the s off the end. root@Tower:~# cd /usr/local/emhttp/plugins/dynamix.system.autofan/ root@Tower:/usr/local/emhttp/plugins/dynamix.system.autofan# ls FanSettings.page README.md default.cfg icons/ images/ include/ scripts/ root@Tower:/usr/local/emhttp/plugins/dynamix.system.autofan# ls scripts/ autofan* rc.autofan* root@Tower:/usr/local/emhttp/plugins/dynamix.system.autofan# Edited September 11, 2022 by SimonF Quote Link to comment
Mors Posted September 11, 2022 Share Posted September 11, 2022 11 hours ago, doron said: Sorry for my confusion. Can you post the output of: ls -la /usr/local/emhttp/plugins This is showing it there right? still confused how I am missing the folder if it comes with the autofan install. Quote Link to comment
Mors Posted September 11, 2022 Share Posted September 11, 2022 So everything is working now, I assume somewhere along the way (beyond the typo in SimonF's post, which I didn't catch either) I assume I must have had a typo myself. Though I find it very strange that I can't browse to the folder in Krusader, I am sure I have a setting not checked somewhere. The big thing was finally seeing something about the MC command, which might be second nature to all your Linux guru's but until I remembered that is how you easily navigate and do things like put this script in the folder I felt like I was taking crazy pills a bit. One of those things where there is just so much info, and so many spaceinvader videos, that finding what you're looking for, and I spent a semi long googling and searching around these forums, can end up being quite daunting since you get a lot of relevant but not specific info. Anyways, thanks to both @SimonF and @doron . If I can trouble you for one more question, now that I see what I did, why would you need a script or anything further to make this work everytime on boot? Since we replaced the already used script with your new code, wont this just automatically run on boot since Autofan uses this script? Quote Link to comment
doron Posted September 11, 2022 Author Share Posted September 11, 2022 If I can trouble you for one more question, now that I see what I did, why would you need a script or anything further to make this work everytime on boot? Since we replaced the already used script with your new code, wont this just automatically run on boot since Autofan uses this script?All these folders are re-created each time you reboot Unraid (technically, all plugins are re-installed on boot). The filesystem you are seeing is in memory. So, yes the hack needs to be replaced each boot.Good news is that author of autofan has finally picked up my fix and hopefully he will make it into an official fix.Sent from my tracking device using Tapatalk Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.