Im doing a data re-build on 2 disks. I upgraded 2 of my 2TB disks to 4TB disks. So far so good doing a dual re-build. (I have back ups and the original drives still so I figured to give it a go)

 

Looking in the shares folder, I have some inconsistency on whats protected (Green Triangle). The share comment where it's cache only is just that cache only.

 

Appdata and Downloads (Cache only) are correct. But Upload, domains and system show the orange triangle. I dont think that's correct, no data / files / folders are on the array for those shares. They should be Green protect by cache pool?

 

unless this has something to do with the Enable copy on write setting? (Mine are all Auto) or another setting? but I cant seem to find it when I compare settings of Downloads to Upload.

 

Or is the cache drives part of the rebuild, not sure if what I see is correct or a bug.

 

 

Parity finished, all back to Green. 

Having issues with contacting the beta machine, can no longer access web gui, pings unresponsive and putty wont connect either. However dockers still running and working. Plex still works and OpenVPN-AS but looks like going to have to do hard reset as I cant even downgrade to stable version.

 

Try one thing first.  Give a quick push of the power button and see if your server shuts down gracefully.  I know that is one of the features of the Powerdown plugin but it may also exist in LT's powerdown routine.  The Powerdown plugin will also write out either the syslog or diagnostic file to the Flash Drive if it is successful.

 

Sorry so everything is actually working but when I RDP to my windows machine it doesnt allow me to connect to //tower/ but I can connect to //server/ which is 1.6.9

 

So not sure if this might be a vpn issue or firewall rule.

On beta 21, I'm also experiencing problem with copying large files to the server.  I do have a VM running, but the file transfers are usually from a secondary unraid server to my main unraid server, so nothing is copied to/from the VM.

 

The copies start fine (70-80 Mbps), but within a few seconds they slow down to a crawl, and eventually stop altogether.  At the same time unraid web gui becomes unresponsive.  In the last few times this happened, I was able to stop the array, but not to restart the server (had to manually hit the reset button). 

 

Changing the num_stripes setting didn't seem to make any difference, the first large file copy hung the server again, however I was able to stop the array and restart the server as well from the gui, so maybe an improvement?  I've never been able to see anything in the log suggesting a problem.  After restarting, the server seems fine for a few days.

 

Try disabling network offload, see the Tips and Tweaks page.  The plugin makes the change easy to perform.

 

I've installed stats plugin and run a test copy: ~16GB file from my windows 10 PC to the main unraid server.  The copy starts fast as usual, and I can see almost all RAM getting used up as "cache" (see pic), BTW, is that normal?  When the ram is used up, speed slows down gradually.

 

At around 17:22 I turn off the one VM I have running (it's now set to only use 2GB of ram), and I can see the copy speed up again (bump at 17:23), until the cache is full again.  After 17:36 speed recovers around 20 MBps, and is stable until the end of the copy. 

 

Your description sounds normal, image looks about normal to me, but perhaps I may be missing your point?  Writes are super fast while there's cache room to fill.  I'm not sure if your description is saying it's good, or it's bad, or it's back to normal after the first post?  (Sorry for my confusion, I may be missing what you are trying to point out.)

 

RobJ, I'm afraid did a very poor job at explaining.    I'm definitely experiencing consistently slower than normal copies (down to a few KBps or even zero speed for stretches of time), when large files are involved.  I did not seem to matter if:

- the VM is running or not (except for a small speed bump if the VM was on, and is turned off during the copy)

- the num_stripes fix is set to 8192 or left a default

- network offload is on or off

 

I actually went back to 6.19 last night, and to my surprise the problem persisted, so I'm now focusing at ruling out a problem at my end. I'll report back if I find anything.

Not a big deal but shouldn't these notifications be the same?

 

Dual parity sync after a new config:

 

Event: unRAID Parity disk error
Subject: Warning [TOWER5] - Parity disk, parity-sync in progress

Event: unRAID Parity2 error
Subject: Warning [TOWER5] - Parity2, drive not ready, content being reconstructed

I had the same notification this morning. I shrunk the array and did a parity sync with exactly the same messages.

When trying to configure SMTP notifications, using Zoho mail, dynamix got completely broken and there was this error message:

 

Warning:syntax error, unexpected $end, expecting TC_DOLLAR_CURLY or TC_QUOTED_STRING or '"' in /boot/config/plugins/dynamix/dynamix.cfg on line 15 in /usr/local/emhttp/plugins/dynamix/include/Wrappers.php on line 19 Warning: array_replace_recursive(): Argument #2 is not an array in /usr/local/emhttp/plugins/dynamix/include/Wrappers.php on line 19 Warning: extract() expects parameter 1 to be array, null given in /usr/local/emhttp/plugins/dynamix/template.php on line 30

 

 

Thanks,

anthonws.

When trying to configure SMTP notifications, using Zoho mail, dynamix got completely broken and there was this error message:

 

Warning:syntax error, unexpected $end, expecting TC_DOLLAR_CURLY or TC_QUOTED_STRING or '"' in /boot/config/plugins/dynamix/dynamix.cfg on line 15 in /usr/local/emhttp/plugins/dynamix/include/Wrappers.php on line 19 Warning: array_replace_recursive(): Argument #2 is not an array in /usr/local/emhttp/plugins/dynamix/include/Wrappers.php on line 19 Warning: extract() expects parameter 1 to be array, null given in /usr/local/emhttp/plugins/dynamix/template.php on line 30

 

 

Thanks,

anthonws.

Try getting rid of any single or double quotes in the password

 

RobJ, I'm afraid did a very poor job at explaining.    I'm definitely experiencing consistently slower than normal copies (down to a few KBps or even zero speed for stretches of time), when large files are involved.  I did not seem to matter if:

- the VM is running or not (except for a small speed bump if the VM was on, and is turned off during the copy)

- the num_stripes fix is set to 8192 or left a default

- network offload is on or off

 

I actually went back to 6.19 last night, and to my surprise the problem persisted, so I'm now focusing at ruling out a problem at my end. I'll report back if I find anything.

 

Are you writing to a ReiserFS drive that is quite full?

In case it hasn't been posted here, I was able to fix my hardware passthrough issue (in ESXi) using the following

fix.  So I'm now able to run 6.2 virtualized.

RobJ, I'm afraid did a very poor job at explaining.    I'm definitely experiencing consistently slower than normal copies (down to a few KBps or even zero speed for stretches of time), when large files are involved.  I did not seem to matter if:

- the VM is running or not (except for a small speed bump if the VM was on, and is turned off during the copy)

- the num_stripes fix is set to 8192 or left a default

- network offload is on or off

 

I actually went back to 6.19 last night, and to my surprise the problem persisted, so I'm now focusing at ruling out a problem at my end. I'll report back if I find anything.

 

Are you writing to a ReiserFS drive that is quite full?

 

I write to a (samba) share.  All the drives are XFS.  The array is ~87% full, but there is still 4.4TB of total space available. The drive with the least free space still has 170GB free, and most of the other drives have > 300GB of free space.

In case it hasn't been posted here, I was able to fix my hardware passthrough issue (in ESXi) using the following fix.  So I'm not able to run 6.2 virtualized.

 

Is it safe to assume that you meant to say that after the *fix* that you are s/not/now able to run 6.2 virtualized?

In case it hasn't been posted here, I was able to fix my hardware passthrough issue (in ESXi) using the following fix.  So I'm not able to run 6.2 virtualized.

 

Is it safe to assume that you meant to say that after the *fix* that you are s/not/now able to run 6.2 virtualized?

 

Yes, meant to say now.  Thanks for the correction.

Wanted to post this issue here in case it's beta related. Can replicate with plugins disabled. Diags attached.

 

 

https://lime-technology.com/forum/index.php?topic=49380.0

When trying to configure SMTP notifications, using Zoho mail, dynamix got completely broken and there was this error message:

 

Warning:syntax error, unexpected $end, expecting TC_DOLLAR_CURLY or TC_QUOTED_STRING or '"' in /boot/config/plugins/dynamix/dynamix.cfg on line 15 in /usr/local/emhttp/plugins/dynamix/include/Wrappers.php on line 19 Warning: array_replace_recursive(): Argument #2 is not an array in /usr/local/emhttp/plugins/dynamix/include/Wrappers.php on line 19 Warning: extract() expects parameter 1 to be array, null given in /usr/local/emhttp/plugins/dynamix/template.php on line 30

 

 

Thanks,

anthonws.

Try getting rid of any single or double quotes in the password

[/quote

 

Thanks! Will do!

In case it hasn't been posted here, I was able to fix my hardware passthrough issue (in ESXi) using the following

fix.  So I'm now able to run 6.2 virtualized.

 

You're a lifesaver, without ESXi support I would have to look elsewhere, thank you!

New issue here:  Last night I noticed that videos wouldn't play on any of my devices from my plex server docker.  This morning checking the unRAID box showed me all the drives powered down and Plex still wouldn't play.  Thinking I needed to reboot the box I tried to shut the dockers down -- all shut down except for the Crashplan docker.  I tried to take the array offline through the gui and it accepted the command, but then became unresponsive.  Got the diagnostics via the command line and attempted to restart it using the shutdown -r command, but nothing happened.  Had to power off and power back on.  Diags attached.

 

Edit:  to clarify, shutdown -r said something like "RESTARTING NOW!", but then nothing happened.

 

Same thing happened again and I think I can easily reproduce it.  The server becomes unresponsive (SMB shares), a look at the GUI shows all drives spun down, and after a couple of clicks the GUI becomes unresponsive. Have to cycle power to get it working again.

 

The trigger seems to be having my Win10 VM running.  I'd left it turned off for a few days and everything worked fine.  I turned it on yesterday and within a few hours this happened.  What else can I do to troubleshoot?

Just a brief update, we are pretty confident we have discovered the bug causing deadlocks and system hangs and are in the process of testing patched code now before rolling out a new release.  Thank you all for your patience with us as we worked to get to the bottom of this very nasty bug.

Just a brief update, we are pretty confident we have discovered the bug causing deadlocks and system hangs and are in the process of testing patched code now before rolling out a new release.  Thank you all for your patience with us as we worked to get to the bottom of this very nasty bug.

 

That's great.  Thanks for letting us know.

Can I suggest a feature / option now that you have NVME support?

 

Would it be possible to set a 2nd set of temperature warnings / thresholds for NVME drives?

 

They get really hot and have a much higher temperature range vs SATA SSD / mechanical drives. If the mover is running a large transfer these drives can easily spike to 60C+ (They thermal throttle at 70C)

 

If I leave the default thresholds I would get heat warnings constantly. Would be nice to set the array to one set of temperature thresholds and the cache pool or NVME to another.

Can I suggest a feature / option now that you have NVME support?

 

Would it be possible to set a 2nd set of temperature warnings / thresholds for NVME drives?

 

They get really hot and have a much higher temperature range vs SATA SSD / mechanical drives. If the mover is running a large transfer these drives can easily spike to 60C+ (They thermal throttle at 70C)

 

If I leave the default thresholds I would get heat warnings constantly. Would be nice to set the array to one set of temperature thresholds and the cache pool or NVME to another.

You can change the temp threshold for each drive separately. Click on the drive name under the main tab

Ahh, thanks, I looked at that, Must be something I need to change with the array offline. (And didn't realize the greyed out numbers are just default and I can override it)

 

Thank you.

Well, I finally got around to setting up a test server for v6.2, and noted a couple of anomalies.  Not sure if these have already been reported (I scanned this thread, but not all of the previous ones) ... but here's what I noted today while setting it up.

 

I used an old system with a C2SEE board with Pentium E6300, 4GB, and 10 old 1.5TB and 2TB drives (reduced to 9 after 30 minutes, as I'll noted below).

 

I configured the system with the two newest 2TB drives as parity, and 6 2TB and 2 1.5TB data drives, and started the array.

After about 30 minutes I checked on the status, and noticed that one of the 2TB drives had already had 5 read errors, so I decided to simply reduce the array by one drive, so I stopped the parity sync.

 

Anomaly #1:  I then did a New Config, and assigned the same two parity drives and 7 of the data drives (excluding the one I didn't want to use) ... and then Started the array.    The system did NOT start a parity sync, but claimed that parity was already good      Clearly it was NOT.

 

So I then did another New Config, and assigned only the 7 data drives -- leaving parity unassigned.    I then Started the array; formatted the data drives; stopped the array; assigned the two parity drives ... and Started the array, and the system then started a parity sync with no problem.

 

Anomaly #2:  During the parity sync, I would check on the status about every 30-60 minutes.    More often than not, when I refreshed the page, only the "bottom section" was shown -- the area where the disks are displayed on the Main tab was blank (the section labeled "Array Devices".    A refresh of the page would fix this ... but it happens VERY often.

 

The sync just finished before I wrote this, so I haven't had a chance to really do much with it yet.  I'm planning to copy several TB of data; "fail" a drive (yank it out mid-operation); and then fail a 2nd drive while rebuilding the "failed" one over the new few days.    I presume all will work perfectly, but just though I'd mention the behaviors I noted when setting it up.

 

Anomaly #1:  I then did a New Config, and assigned the same two parity drives and 7 of the data drives (excluding the one I didn't want to use) ... and then Started the array.    The system did NOT start a parity sync, but claimed that parity was already good      Clearly it was NOT.

 

Are you sure you didn't check the "parity is already valid" checkbox by mistake? It happened to me sometimes since it's in the same place as the "I'm sure I want to this" checkbox (when displayed).

 

I've done tens of new configs with single and dual parity and a parity sync always begins if not checking the trust parity box.

Anything's possible, although I'm reasonably sure I didn't do that.    I had the same thought, but I'm ALMOST certain I didn't do that      But it certainly could be what happened ...

 

Is there any way to still mount the drives without an Internet connection to access my data? Wasn't aware of the requirement and now am unable to get hold of the shares due to not having access to the net.

Or is there documentation for configuring internal wifi cards?