unRAID Server Release 6.2.0-rc5 Available

[GHunter]

Upgraded to RC5 from RC4 and everything seems to be working well so far. I mentioned a possible problem quoted below which seems to have been resolved with the RC5 release.

 

Thanks!

 

Gary

 

Upgraded to RC4 from RC3. Everything appears to work fine.

 

Also added a 2nd parity drive 

 

Noticed something in my log files that are filling them up and not sure if there is something I can do on my end.

 

My syslog has a ton of entries like this:

 

Aug 23 00:41:55 FileSvr kernel: xhci_hcd 0000:00:14.0: URB transfer length is wrong, xHC issue? req. len = 0, act. len = 4294967288

 

And my VM log has a ton of these entries:

 

libusb: error [op_clear_halt] clear_halt failed error -1 errno 71

 

Attaching my diagnostics here minus the vm log. I'll post the vm log in a separate post.

 

Gary

 

 

 

Here is my VM log as mentioned above. I had to trim it cause even zipped, it was still bigger than 320k.

 

Gary

[jonp]

- add experimental global share setting: "Tunable (enable Direct IO)"

 

Why are new experimental features being added in an RC?

 

This.  RCs are for bug fixes, not adding more shit to break.  Adding stuff in RC5 totally and utterly defeats the purpose of an RC.  RC should be a feature freeze then bug fix, nothing else.

 

You guys are making a mountain out of a molehill. The new option is disabled by default and has to be turned on manually from the share settings page. This new "feature" is new to unRAID, but not new to fuse and has been available in fuse for some time now. It's not like this is akin to dual parity or something as far as a feature goes. In addition, we had done testing with this far before the RC phase, we just hadn't included the tickbox for turning it on in the web GUI.

 

The main purpose for this new option is for 10gbps network transfers as Johnnie Black already saw. He jumped from 700MB/s to full 1GB/s as a result.

[SpaceInvaderOne]

- add experimental global share setting: "Tunable (enable Direct IO)"

 

Why are new experimental features being added in an RC?

 

This.  RCs are for bug fixes, not adding more shit to break.  Adding stuff in RC5 totally and utterly defeats the purpose of an RC.  RC should be a feature freeze then bug fix, nothing else.

 

You guys are making a mountain out of a molehill. The new option is disabled by default and has to be turned on manually from the share settings page. This new "feature" is new to unRAID, but not new to fuse and has been available in fuse for some time now. It's not like this is akin to dual parity or something as far as a feature goes. In addition, we had done testing with this far before the RC phase, we just hadn't included the tickbox for turning it on in the web GUI.

 

The main purpose for this new option is for 10gbps network transfers as Johnnie Black already saw. He jumped from 700MB/s to full 1GB/s as a result.

 

I'm always happy to have any new features myself. In my opinion any new feature is a step forward. I have faith in you guys and you are conststantly improving the system which is great.

I would rather have new features sooner rather than later. If i was so worried to not try a beta or rc then i would stick to a stable release. Lets be honest for about 90% of us it wouldn't really matter if an error happened due to using a beta or an rc. We can just roll back to an earlier release until its sorted. Im sure none of our rigs are running any life support systems lol 

[limetech]

- get rid of release validation for -rc releases with Basic/Plus/Pro

 

Does this mean that the "phone home" 'feature' has been removed and that it will start up in the absence of an Internet connection?

 

That would be my interpretation as well but the new wording for the feature  (release validation ) adds just enough doubt to make me want to confirm this as well.

For Basic/Plus/Pro keys no interaction with any outside server takes place.  Trial still requires access to our key server to validate.  You could of course test this yourself by unplugging your network cable and reboot your server.

 

Also CVE-2016-5389 has been ommited from the changelog. Since there is an SSA for this it should be included. Please confirm it is fixed by adding it to the changelog as usual.

 

Refer to:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5389

 

The correction for CVE-2016-5696 actually took place in linux kernel 4.4.18 which we upgraded to in 6.2.0-rc4.  The full change log available from the webGui Plugins page or our website Download page reflects that.

[limetech]

RCs are for bug fixes, not adding more shit to break.  Adding stuff in RC5 totally and utterly defeats the purpose of an RC.  RC should be a feature freeze then bug fix, nothing else.

 

The addition of this option is a bug fix: it fixes slower than expected 10Gb/sec performance, and we chose to fix it in this release.  We explicitly marked this "experimental" and "off" by default because it has only limited testing.

[jonp]

- add experimental global share setting: "Tunable (enable Direct IO)"

 

Why are new experimental features being added in an RC?

 

This.  RCs are for bug fixes, not adding more shit to break.  Adding stuff in RC5 totally and utterly defeats the purpose of an RC.  RC should be a feature freeze then bug fix, nothing else.

 

You guys are making a mountain out of a molehill. The new option is disabled by default and has to be turned on manually from the share settings page. This new "feature" is new to unRAID, but not new to fuse and has been available in fuse for some time now. It's not like this is akin to dual parity or something as far as a feature goes. In addition, we had done testing with this far before the RC phase, we just hadn't included the tickbox for turning it on in the web GUI.

 

The main purpose for this new option is for 10gbps network transfers as Johnnie Black already saw. He jumped from 700MB/s to full 1GB/s as a result.

 

I'm always happy to have any new features myself. In my opinion any new feature is a step forward. I have faith in you guys and you are conststantly improving the system which is great.

I would rather have new features sooner rather than later. If i was so worried to not try a beta or rc then i would stick to a stable release. Lets be honest for about 90% of us it wouldn't really matter if an error happened due to using a beta or an rc. We can just roll back to an earlier release until its sorted. Im sure none of our rigs are running any life support systems lol 

 

Thank you for your support and vote of confidence.

[BRiT]

RCs are for bug fixes, not adding more shit to break.  Adding stuff in RC5 totally and utterly defeats the purpose of an RC.  RC should be a feature freeze then bug fix, nothing else.

 

The addition of this option is a bug fix: it fixes slower than expected 10Gb/sec performance, and we chose to fix it in this release.  We explicitly marked this "experimental" and "off" by default because it has only limited testing.

 

In addition there is an "experimental" setting under Global Share settings to turn on Direct IO mount option for user share file system.  This improves write performance and lets us reach "wire speed" for 10Gb/sec Ethernet to cache disk/pool of SSD's.

 

Management:

 

- add experimental global share setting: "Tunable (enable Direct IO)"

 

Any additional details you can share with us about this new feature, such as Pros and Cons? But more importantly, what should users keep a look out for with this new experimental mode? What's the worst that could happen when using this experimental mode?

[ajgoyt]

RCs are for bug fixes, not adding more shit to break.  Adding stuff in RC5 totally and utterly defeats the purpose of an RC.  RC should be a feature freeze then bug fix, nothing else.

 

The addition of this option is a bug fix: it fixes slower than expected 10Gb/sec performance, and we chose to fix it in this release.  We explicitly marked this "experimental" and "off" by default because it has only limited testing.

 

Tom I need the 10gb when moving files from workstation to my server, So since this is the last RC before the official barring no major issues, I should be fine to upgrade from 6.1.9, your thoughts?  I know there's always a risk with a BETA or RC or even stable - So are we weeks away from official 6.2 or?

[jonp]

 

Any additional details you can share with us about this new feature, such as Pros and Cons? But more importantly, what should users keep a look out for with this new experimental mode? What's the worst that could happen when using this experimental mode?

 

It only should be used if you are using 10gbps networking and aren't getting full transfer rates when copying data to user shares.  There are no other comments to provide other than what was already written in the help text, which indicates that enabling this feature may impact read performance.

[Frank1940]

Updated to v6.2 rc5 on the Test Bed server late last night.  I almost immediately started a non-correcting parity parity check.  Time of 10 hr, 40 min, 21 sec was 18 seconds faster than for ver6.2 rc4.  ( Checking time for a single parity setup on this hardware would be in the 8 hour area.)  Basically, no change in performance but none was really expected at this point. 

[NAS]

- get rid of release validation for -rc releases with Basic/Plus/Pro

 

Does this mean that the "phone home" 'feature' has been removed and that it will start up in the absence of an Internet connection?

 

That would be my interpretation as well but the new wording for the feature  (release validation ) adds just enough doubt to make me want to confirm this as well.

For Basic/Plus/Pro keys no interaction with any outside server takes place.  Trial still requires access to our key server to validate.  You could of course test this yourself by unplugging your network cable and reboot your server.

 

 

To be fair that only tests that the server boots and not that the system doesn't call home. The two were related previously but they dont have to go hand in hand.

 

 

The correction for CVE-2016-5696 actually took place in linux kernel 4.4.18 which we upgraded to in 6.2.0-rc4.  The full change log available from the webGui Plugins page or our website Download page reflects that.

 

oops my mistake sorry. I have not been keeping fully up do date as I used to with unRAID CVEs because I dont run the RC (due to the call home) and I gave up hope on 6.1.9 a few months ago. I will start again post RC5 with renewed vigor.

 

 

As for the "experimental" feature in RC5. You got to realize guys do yourself no favours by adopting a non standard release methodology but naming it identically to the standard.

 

There is no malice here but you have to expect that if you release an RC with something labelled experimental to a group of Linux enthusiasts and dont take time to define whats RC means to you then there is only one outcome to expect.

 

I strongly suggest the solution to this is to just adopt the standard model. The correct place to discuss more on this is here http://lime-technology.com/forum/index.php?topic=42640.0 and I hope LT and all people complaining join the thread the hammer it out.

[limetech]

As for the "experimental" feature in RC5. You got to realize guys do yourself no favours by adopting a non standard release methodology but naming it identically to the standard.

It's not a feature, it's a bug fix.

[limetech]

RCs are for bug fixes, not adding more shit to break.  Adding stuff in RC5 totally and utterly defeats the purpose of an RC.  RC should be a feature freeze then bug fix, nothing else.

 

The addition of this option is a bug fix: it fixes slower than expected 10Gb/sec performance, and we chose to fix it in this release.  We explicitly marked this "experimental" and "off" by default because it has only limited testing.

 

Tom I need the 10gb when moving files from workstation to my server, So since this is the last RC before the official barring no major issues, I should be fine to upgrade from 6.1.9, your thoughts?

 

It's been fine to upgrade for months.

[NAS]

As for the "experimental" feature in RC5. You got to realize guys do yourself no favours by adopting a non standard release methodology but naming it identically to the standard.

It's not a feature, it's a bug fix.

 

Again its all in the wording.

 

No one can possibly be expected to read "- add experimental global share setting: "Tunable (enable Direct IO)"" as a bug fix changelog.

 

I suggest that even if it is a bug fix that it should have been in the next beta testing and not the last RC. Thats how most people would have done it.

[limetech]

As for the "experimental" feature in RC5. You got to realize guys do yourself no favours by adopting a non standard release methodology but naming it identically to the standard.

It's not a feature, it's a bug fix.

 

Again its all in the wording.

 

No one can possibly be expected to read "- add experimental global share setting: "Tunable (enable Direct IO)"" as a bug fix changelog.

 

I suggest that even if it is a bug fix that it should have been in the next beta testing and not the last RC. Thats how most people would have done it.

 

Point taken.  But it has been properly illuminated in this topic and I'm not going to generate a -rc6 just to change the wording of a change log entry.

[phbigred]

Agreed at this point lets get stable released, you guys are doing good work! I understand the security concerns, agree with most however the branch of 6.1 needs to be severed and move forward. That's what companies like EMC do, only difference is they continue the support for bug fixes for a while. It's a "small" shop we can't expect them to keep everything running concurrently. I took the leap to 6.2 in the early betas and haven't looked back. Let's keep this ball rolling and fix the nfs issue after release.

[bonienl]

It is not explicitly mentioned in the release notes but the issue described here is addressed as well.

 

Now any change in interfaces will update the network-rules file accordingly, and it is not needed to delete the file manually (if existing). unRAID will automatically adapt to the new situation.

 

[ccollinscj]

Drop down out of the network setting for the subnet mask does not give you the option for a 255.0.0.0 subnet,  it only has 255.255.0.0

[bonienl]

Drop down out of the network setting for the subnet mask does not give you the option for a 255.0.0.0 subnet,  it only has 255.255.0.0

 

Do you need a /8 network (16.7M addresses) ?

 

[NAS]

As for the "experimental" feature in RC5. You got to realize guys do yourself no favours by adopting a non standard release methodology but naming it identically to the standard.

It's not a feature, it's a bug fix.

 

Again its all in the wording.

 

No one can possibly be expected to read "- add experimental global share setting: "Tunable (enable Direct IO)"" as a bug fix changelog.

 

I suggest that even if it is a bug fix that it should have been in the next beta testing and not the last RC. Thats how most people would have done it.

 

Point taken.  But it has been properly illuminated in this topic and I'm not going to generate a -rc6 just to change the wording of a change log entry.

 

Just for clarity on what I was saying and I really dont expect a reply I was not suggesting RC6 i was saying that the model people expect when you announce an RC is that all the new stuff, as in every single thing would stop and traditionally been pushed to the 6.3 cycle.

 

Any other ramblings I will post in the right thread. I really dont want to OT this one.

 

 

 

 

[ajgoyt]

RCs are for bug fixes, not adding more shit to break.  Adding stuff in RC5 totally and utterly defeats the purpose of an RC.  RC should be a feature freeze then bug fix, nothing else.

 

The addition of this option is a bug fix: it fixes slower than expected 10Gb/sec performance, and we chose to fix it in this release.  We explicitly marked this "experimental" and "off" by default because it has only limited testing.

 

Tom I need the 10gb when moving files from workstation to my server, So since this is the last RC before the official barring no major issues, I should be fine to upgrade from 6.1.9, your thoughts?

 

It's been fine to upgrade for months.

 

Ok Tom I will update tonight following the instructions for 6.2, I run No vm's but I do run a few dockers Plex - Emby etc If I recall I will have to rebuild / reload the dockers? 

 

what is the safest - install from the plugin or download and generate a fresh install? in either case i will back up my thumb drive 1st...

 

 

[isvein]

Looking forward to the release of 6.2

[ryoko227]

Thank you for all your hardwork getting this put together LT. Already have RC5 running on both the office and home rigs. Updated without issues. 

[garycase]

Updated without issue => parity check running now just to confirm, but don't anticipate any problem.

 

[PeterB]

Updated from v6.1.9 without any apparent problem.  Will run for a few days then try adding second parity drive.

 

Thanks for all the hard work!