Interstellar
Members
-
Joined
-
Last visited
Everything posted by Interstellar
-
How are you measuring those numbers? Im just curious as those numbers are less than mine and I don’t see how or why. The following draws 29W at the absolute minimum (measured via three methods) but typically power meter shows 30-31W when all drives spun down. i5-8600T (under-volted), saved 1W at idle and gains me 5% performance when hitting 35W power limit! 16GB DDR4 (non-ECC) H310CM-HDV/M.2 1TB M2 Intel Quad-Port NIC (adds 4-5W) Four 14TB WD (Shucked) Seasonic 550W Platinum I have less disks (spun down call that 0.4W a disk based on data sheets) means your 1.6W higher nominally. 48GB more memory, difficult to put numbers on it but 0.1W/GB seems not far off so that’s another 4.8W. Plus you have ECC which adds another chunk too due to the IO overheads and chip on the PCB. Plus im running a T CPU which typically idles a tad better than the higher TDP CPUs due to being less leaky silicon (lower idle voltage). Taking the NICs out of the equation: Your machine: 18W My machine: 25W So unless my motherboard/PSU at these low loads are totally rubbish efficiency wise you should be in the 35W region, not 18…! A little HP i3-8100T SFF desktop I tested drew 11W at idle, and that had 8GB RAM, no HDDs other than a small SSD and a 180W 12V only PSU in it. When we are talking about these low numbers, we need to be taking accurate measurements 👍 Next upgrade will be when the ATX12VO stuff comes along, then I’ll upgrade to a 13/14th Gen T CPU, 300W PSU, 32GB DDR5, etc. Hopefully bring system power down below 20W.
-
@bonienl Should I raise these bugs on GitHub for resolution? Still suffering from them...
-
I am also having this problem, bonienl can you add some code that gives us the option to increase the PHP memory limit? This problem isn't going away, disks are getting larger, thus filling with more files. So two bugs with the script at the moment: 1. SHA256 "Check Export" button does not work correctly. 2. 128MB PHP limit is too low. (not strictly a bug, but it doesn't work with it set at 128MB so might as well be one)
-
There are hash files there, the Export function works. The Verify Export function does not work, when the relevant disk is checked... "Finished - checked 0 files, skipped 0 files. Found: 0 mismatches, 0 corruptions. Duration: 00:00:00" So I cannot start a manual verify. A automatic verify does start the check however.
-
Still struggling to get this to manually do a verify after a disk rebuild. The Export then Check Export just ends up with the following when disk 3 selected... Finished - checked 0 files, skipped 0 files. Found: 0 mismatches, 0 corruptions. Duration: 00:00:00 Obviously wrong. Nothing in the logs either, just trying to make it do an automatic daily check instead to see if that works... At the moment I do not believe this plugin works correctly, sorry Bonienl. Edit: Automatic verify seems to work, the Check Export button does NOT work.
-
Randomly hit by this today, nothing else of mine is suffering from this problem (Mac, RPIs, Windows machines and indeed a VM on the NAS itself!) Seems similar issues reported here: During startup you can see I can ping bbc.co.uk at a regular 1 sec cadence, as is expected. However between 1650491180 and 1650491186 something happens to cause the ping DNS resolution to slow to a crawl. [1650491160.677062] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=2 ttl=57 time=7.19 ms [1650491161.680240] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=3 ttl=57 time=7.59 ms [1650491162.680644] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=4 ttl=57 time=7.59 ms [1650491163.682572] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=5 ttl=57 time=7.72 ms [1650491164.684427] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=6 ttl=57 time=7.59 ms [1650491165.686395] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=7 ttl=57 time=7.63 ms [1650491166.687953] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=8 ttl=57 time=7.66 ms [1650491167.688993] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=9 ttl=57 time=7.81 ms [1650491168.692176] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=10 ttl=57 time=7.97 ms [1650491169.692828] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=11 ttl=57 time=7.70 ms [1650491170.695271] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=12 ttl=57 time=7.46 ms [1650491171.697118] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=13 ttl=57 time=7.77 ms [1650491172.698616] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=14 ttl=57 time=7.86 ms [1650491173.699806] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=15 ttl=57 time=7.86 ms [1650491174.699658] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=16 ttl=57 time=7.54 ms [1650491175.701393] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=17 ttl=57 time=7.55 ms [1650491176.704215] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=18 ttl=57 time=7.83 ms [1650491177.705895] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=19 ttl=57 time=7.73 ms [1650491178.707608] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=20 ttl=57 time=7.95 ms [1650491179.709268] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=21 ttl=57 time=7.81 ms [1650491180.710587] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=22 ttl=57 time=7.58 ms [1650491186.712848] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=23 ttl=57 time=7.68 ms [1650491188.485948] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=24 ttl=57 time=7.81 ms [1650491188.495136] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=25 ttl=57 time=7.68 ms [1650491194.497036] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=26 ttl=57 time=7.68 ms [1650491199.507572] 64 bytes from 2a04:4e42:200::81 (2a04:4e42:200::81): icmp_seq=27 ttl=57 time=7.85 ms If I decode the unix time, this command is shown in the log: Apr 20 22:46:21 NAS emhttpd: shcmd (18): /etc/rc.d/rc.avahidaemon start If I then run: /etc/rc.d/rc.avahidaemon stop The ping behaviour etc goes back to how it is supposed to be? What is mDNS doing and why is it causing ping name resolution to fall over? (This problem also prevented me from updating dockers, pulling apps, etc and happens in safe mode too). Edit: Happens on 6.9 and 6.10rc3.
-
I have now also come up against this problem. ping google.co.uk starts immediately and has a nice 1 sec cadence. ping bbc.co.uk starts slowly and takes a good few seconds per ping. ping -n bbc.co.uk works as expected. I've nailed it down to something around the mDNS stuff, as before its mentioned in the log everything is OK, once that starts up (well before the array starts) then it all falls over. What is UnRAID doing with mDNS? Edit: To clarify, SSH in and start the ping bbc.co.uk as soon as you can. It works OK for a few seconds until something else is done during the startup and then it goes slow. Edit: Confirmed. Pings start going slow just as this happens: /etc/rc.d/rc.avahidaemon start Running /etc/rc.d/rc.avahidaemon stop Fixes it...
-
Note: This isn't a bug-report per-say, more a thread looking for potential fixes. I've been struggling with this for a while and any 'solutions' I've found on the forums thus far have not been successful. Background: I've been passing through an RX480 without a dongle (i.e. with VNC enabled) absolutely fine for months (up-time of 40+ days at one point), however now as I want to use it as a remote Windows workstation I've tweaked it to make Parsec work properly (4K HDMI Dongle + Parsec). However in that configuration it totally locks up the machine with zero information displayed in the log or on the IPMI KVM view screen (Its a total and immediate lockup... which is useful). In addition any attempt to close a Remote Desktop session also results in the machine totally locking up, a reboot is the only solution. The notes for changing the WDDM thing hasn't made a difference (in any case an update KB is installed that allegedly fixes it). I have the AMD reset plugin installed and I'm running 6.10-rc2 and rc1 prior to that. Two cores + HT isolated (2,3, 6, 7) assigned to the VM, along with 6144MB RAM. Q35-6.1 (i440fx never seems to work for me, gets stuck at the boot screen or Windows stops responding) OVFM TPM USB Controller (3 qemu XHCI) Windows 10 21H2 - totally 100% up-to-date, latest AMD drivers, latest VirtIO drivers, etc... I've now taken the dongle out and added the VNC server back in and I'll test across the next two weeks (Parsec also disabled). Does anyone have any thoughts on what is causing UnRAID (or Windows to cause UnRAID) to completely lock up either by closing a Remote Desktop connection or randomly at some point in time when there is no VNC enabled? If it wasn't for the fact GPU prices are insane at the moment I'd pick something up newer, but alas we are where we are. I'll post the diagnostics plus information on other server configs when I have more time, but for now if anyone has any ideas, please feel free to let me know and I'll try them!
-
Same - it used to be obvious now to do a manual verify but it isn't now. The "Check Export" button does nothing. --> "Check Export Finished - checked 0 files, skipped 0 files. Found: 0 mismatches, 0 corruptions. Duration: 00:00:00" How do I command a manual verify after a disk rebuild and upgrade?!
-
This is still a problem on iOS 15. Can’t for example open any log page (scripts or system). This needs to be resolved, if it’s a webkit thing then open a normal page instead…
-
I'm trying to exclude my "_CCC SafetyNet" folders, using the following command in the GUI... -a '-noleaf \( -name "_CCC SafetyNet" -prune \) -o -print' However, the GUI doesn't like the quotation marks and I end up with just "-a '-noleaf \( -name" in the box. The command seems to be issued correctly however according to the logs, but it STILL looks through the CCC Archive folders (I'm watching lsof!) How can I exclude folders like "_CCC SafetyNet" in the GUI? Thanks!
-
Really? Seems a bit odd to create a dir/file in RAM rather than say "does not exist"? Alternatively, given that as far as I'm aware there is a fixed list of potential paths to the array(s). Therefore something like if the path contains "/mnt/user" or "/mnt/diskX" or "/mnt/cache" then it is an array dependent VM/docker and will be skipped at initial docker/VM starts. Then when you start the array you can see which dockers/VMs haven't been started due to having an array dependency and start them then. Given only one of the 20 odd VMs/Dockers I currently run depend on the array (and is actually the only reason I have a "cache" drive (I don't use the array cache feature because of performance reasons) and some would benefit from not being array dependent, then its a fairly key feature for me going forward and actually the only one I can currently think of that I need from UnRAID.
-
Surely the same way that you do now for a path that doesn't exist?
-
+1 here. Daft that I have to stop my PfSense VM to do various things like change SMB settings, change array settings, etc. VMs/dockers should be able to run irrespective of the state of the array.
-
Background Two 320GB 2.5" disks setup as a RAID 0 pool, total available space as expected (640GB) used as CCTV storage using beta30. (I'm going to wait until I have to disconnect the server to update to 35). However, I've noticed that the CCTV camera stops recording once the disk is "full", i.e. 638GB of 640GB used. I thought I'd messed up the config so I deleted the pool, wiped the drives and then configured another RAID 0 pool, again 640GB available. However the CCTV cameras have now stopped recording... Looking closer... (this is after I've started a balance), RAID0 line showed a total of 2GB before the start... Data, RAID1: total=293.00GiB, used=293.00GiB Data, RAID0: total=6.12GiB, used=4.06GiB System, RAID1: total=32.00MiB, used=64.00KiB Metadata, RAID1: total=1.00GiB, used=342.30MiB GlobalReserve, single: total=337.02MiB, used=0.00B Why is SMB and UnRAID UI stating 640GB available, yet the data is being recorded in RAID1 mode?? Have I messed up the config here again, or is there a bug? Edit: Nothing obvious in the logs relating to either the disks, the pool itself or SMB giving a write error. Also cancelled the balance and hit the 'convert to RAID 0' mode which seems to be balancing the disks again. Edit 2: I've deleted data off the drives, hit the convert to RAID 0 button, once that's finished I'll let the CCTV record again.
-
Background: I had another thread open (which I've now deleted) as I thought the smb message I got at the time was relevant. Short Story: Previously I used to backup directly to /mnt/disk1/Backup/XXX and this seemingly worked just fine. However a few months ago now these started to regularly fail, especially when backing up my Mac's boot drive which has some very long and deep file paths. After some testing I found out that going via the user share "Backup" works what appears to be absolutely perfectly with only minor errors (i.e. the backup completes compared to failing completely). If I move back to "/mnt/disk1/Backup/XXX" things start to fail again. This applies to both rsync and CCC. On some occasions the SMB mount point is actually ejected (along with all the others). These are the errors that I can see in syslog during the backups: Jun 1 18:34:13 TOWER-NAS smbd[24819]: [2020/06/01 18:34:13.839583, 0] ../../lib/param/loadparm.c:414(lp_bool) Jun 1 18:34:13 TOWER-NAS smbd[24819]: lp_bool(no): value is not boolean! Jun 1 18:35:21 TOWER-NAS smbd[29422]: [2020/06/01 18:35:21.358475, 0] ../../lib/param/loadparm.c:414(lp_bool) Jun 1 18:35:21 TOWER-NAS smbd[29422]: lp_bool(no): value is not boolean! Jun 1 18:37:52 TOWER-NAS smbd[9607]: [2020/06/01 18:37:52.683904, 0] ../../lib/param/loadparm.c:414(lp_bool) Jun 1 18:37:52 TOWER-NAS smbd[9607]: lp_bool(no): value is not boolean! Jun 1 18:38:13 TOWER-NAS smbd[11372]: [2020/06/01 18:38:13.076973, 0] ../../lib/param/loadparm.c:414(lp_bool) Jun 1 18:38:13 TOWER-NAS smbd[11372]: lp_bool(no): value is not boolean! Jun 1 18:39:28 TOWER-NAS smbd[17024]: [2020/06/01 18:39:28.851723, 0] ../../lib/param/loadparm.c:414(lp_bool) Jun 1 18:39:28 TOWER-NAS smbd[17024]: lp_bool(no): value is not boolean! Jun 1 18:42:19 TOWER-NAS smbd[31108]: [2020/06/01 18:42:19.593322, 0] ../../lib/param/loadparm.c:414(lp_bool) Jun 1 18:42:19 TOWER-NAS smbd[31108]: lp_bool(no): value is not boolean! Jun 1 18:42:52 TOWER-NAS smbd[429]: [2020/06/01 18:42:52.433449, 0] ../../lib/param/loadparm.c:414(lp_bool) Jun 1 18:42:52 TOWER-NAS smbd[429]: lp_bool(no): value is not boolean! Jun 1 18:43:18 TOWER-NAS smbd[3406]: [2020/06/01 18:43:18.728991, 0] ../../lib/param/loadparm.c:414(lp_bool) Jun 1 18:43:18 TOWER-NAS smbd[3406]: lp_bool(no): value is not boolean! Jun 1 18:47:55 TOWER-NAS smbd[429]: [2020/06/01 18:47:55.535195, 0] ../../lib/param/loadparm.c:414(lp_bool) Jun 1 18:47:55 TOWER-NAS smbd[429]: lp_bool(no): value is not boolean! Jun 1 18:48:58 TOWER-NAS smbd[30389]: [2020/06/01 18:48:58.740944, 0] ../../lib/param/loadparm.c:414(lp_bool) Jun 1 18:48:58 TOWER-NAS smbd[30389]: lp_bool(no): value is not boolean! The problem with going via the user share is that the performance is much slower. These are the SMB settings at the moment: veto files = /._*/.DS_Store/ case sensitive = yes #unassigned_devices_start #Unassigned devices share includes include = /tmp/unassigned.devices/smb-settings.conf #unassigned_devices_end [global] log level = 0 logging = syslog Enhanced macOS interoperability: Yes Enable NetBIOS: Yes Enable WSD: Yes I originally thought it was something to do with macOS, but given it works via a user share and not a disk share then that points back at UnRAID. There is nothing else in the log that hints at any other problems. Cache_dirs has been tried on and off as well as at different search levels. I've also tried 6.0beta1 - same problems. Why on earth would the user share but not the disk share work OK!? Thanks...!
-
Regarding cache_dirs, is there a way to permanently exclude sub directories? I need "_CCC SafetyNet" excluded... I can't seem to to find a way of doing this?
-
Just before I open a bug topic, can people using Safari check that when you open a sub-window (e.g. the log) that it asks you to login again? Safari: I get the login window on every pop-up (E.g. The 'Log Summary' button) which when you login just takes you to the home 'Dashboard' page again... Chrome: Works I would assume as intended (all works as per pre-6.8) I use Safari 99.999% of the time, so this is a minor annoyance. (This happens on both my iMac and newly installed MBP so it isn't a cache issue).
-
Updated this morning. System totally locked up after about 10 mins. Nothing in the console or flash drive syslog. Forced a reboot - everything ok 8 hours later so hoping it is a one off!
-
Still struggling with this if anyone has any ideas? Cheers.
-
Any ideas why I'm now getting this error in the preview window? (Only change I've made is upgrading from 6.7.1 to 6.7.2) tput: unknown terminal "tmux-256color" Thoughts? Cheers.
-
Im not up to date with the changes that cause your issues, but if it’s a change for newer hardware then you might be SOL. Cant keep putting effort in supporting 10+ year old platforms.
-
Updated my X10SLL-F from a 2014 BIOS to a 2018 one. It made my Intel Pro 1000PT Quad NIC stop working! (New BIOS seems to have fixed a bug where previously the bottom slot would negotiate pci-e v1a but now negotiates v2, and the 1000PT doesn’t work with v2! New NIC inbound! Other than that the flash went fine and everything working...
-
Nope. I think I just pulled the drive and let parity rebuild as it was faster. Although I have a vague recollection that I re-formatted the drives so I could mount them then filled them with a massive/dev/zero file (at full speed!), then did the /dev/md* command to clear the first 500M, then pulled the drive and forced the parity to remain valid. Ended up with a handful of parity errors after the 11 hour check. Not ideal but at least I had a 99.999% valid parity whilst it checked it. System works perfectly otherwise and I haven’t tried it again on newer versions.
-
Not reset when re-started or restarting UnRAID. If I delete the data folder I have to do it again.