unRAID Server Release 5.0 i386 Available


Recommended Posts

syslog without any plugin

 

Total size:	2 TB	
Current position:	2.26 GB (0.1 %)	
Estimated speed:	26.8 MB/sec	
Estimated finish:	20 hours, 41 minutes

 

This was the result :(

 

Last checked on Fri Aug 30 11:58:44 2013 CEST (today), finding 0 errors. 
> Duration: 14 hours, 21 minutes, 12 seconds. Average speed: 38.7 MB/sec

 

Earlier release was this process around 9 hours with speed around 70MB/sec ,

 

Peter_sm ----

 

A bit of a long shot, but ....  Check the smart reports for each drive and see if one of them is having a serious read problem and using its built-in error correction to rebuilt the data on the fly. 

Link to comment
  • Replies 345
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

I had the same issue. I use unodns and my subscription had run out so maybe check your DNS settings.

 

Would that matter if I'm not running anything like unodns and I'm inside the US? And when you updated the GUI did you just click the update button and then BOOM did it just change instantly? or do I have to reset my server?

 

Check post 82 and 87 of this thread (page 6)

 

Maybe still a problem with your DNS, just mine was connected to using unodns

 

 

Link to comment

A bug in v5.0-i386:

In the WebGUI I uncheck the "Correct" checkbox, and start a parity check.  The syslog shows:

Aug 30 09:03:49 ToyServ kernel: mdcmd (41): check CORRECT
Aug 30 09:03:49 ToyServ kernel: md: recovery thread woken up ...
Aug 30 09:03:49 ToyServ kernel: md: recovery thread checking parity...

 

My "mileage" did vary.....yesterday I went back to the stock webGUI and did about the same thing as you (unchecked the "Correct" checkbox) and got the correct result as shown in my syslog:

Aug 29 17:05:05 Tower kernel: mdcmd (17): check NOCORRECT (unRAID engine)
Aug 29 17:05:05 Tower kernel: md: recovery thread woken up ... (unRAID engine)
Aug 29 17:05:05 Tower kernel: md: recovery thread checking parity... (unRAID engine)
Aug 29 17:05:05 Tower kernel: md: using 1536k window, over a total of 2930266532 blocks. (unRAID engine)
Aug 29 17:06:48 Tower kernel: mdcmd (18): nocheck  (unRAID engine)
Aug 29 17:06:48 Tower kernel: md: md_do_sync: got signal, exit... (unRAID engine)
Au

I just let it run for a minute or so........

Link to comment

I am finding two things pretty amazing:

 

1. How few problems are people reported

2. How many people decided to install an RC and then not keep it patched

 

#1 is even more amazing given #2

 

Speaking for myself on #2, I don't want to beta test, but I required support for current hard drives, so I had to either use a 5.0 beta release or abandon UnRAID.    The RC I'm using has been working without issues and every later RC I considered updating to had reports of issues, some even data loss.  I have followed every beta release thread and tried to understand if it is better or worse than what I was already running.  Again, I'm not interested in beta testing and don't want to be the one to find a big data loss oops in an RC.

 

Even now, I'm waiting to see if 5.0 "final" has any major issues.  I don't want to update to 5.0 final and then have a 5.0a to evaluate a couple of days later!

 

I've been using unRAID for over 5 years now and i've not seen a single report of data loss by upgrading unRAID to beta/RC/release or anything. Every case where people experienced data loss was because drives were incorrectly detected as unformatted and they hit the format button, which comes down to user error. Typically it's impossible, he would have to "accidentally" code in a script to delete files or something along those lines. The worst that can (realistically, user errors aside) happen when upgrading is the partition not being detected, and then you have to fix it. There may be some bugs that affect some system, but worse case you can easily downgrade.

 

Call me nuts but I don't even have a test server, I generally upgrade unRAID the day a new version comes out (even back when it was 5.0 betas) and I have almost 83TB of stuff.

Link to comment

Once a build works for you and the longer it works for you the more the FUD factor sinks in. Thinking of all that time (probably undocumented) spent getting the build just right stops most of us from wanting to "boldly go" into the breech of the next rev. If in ain't broke..........

 

At least with unRAID, it's not that big a deal to go back to an earlier build if you encounter problems with a new rev. I'm sure we've all seen those types of posts!

 

Thankfully the move from 4.7 to 5.0, so far, has been pretty smooth; I hope the trend continues!!

Link to comment

I am finding two things pretty amazing:

 

1. How few problems are people reported

2. How many people decided to install an RC and then not keep it patched

 

#1 is even more amazing given #2

 

what is so amazing?

I am still running 5.0 Beta 13 (NOTE: BETA) and have been running for 2 years straight.

no issues what so ever

 

My friend is the same as you. "I only need 3TB support, it's working fine, I have no reason to upgrade past this beta version...". He the guy who never upgrades any of his programs if he's not having issues, "if it's not broke don't fix it".

 

Well 5.0 final came out, I upgrade both my servers from RC15. No issues whatsoever, headache free, took 5 minutes for 2 servers. He upgrades from his older version, and I end up on the phone with him for no less than 6 hours troubleshooting the upgrade. What was the problem? Well it seems the Sabnzbd plugin, for whatever reason, didn't like one of the many changes and kept hanging his entire array. However, I use the exact same Sabnzbd version and had no problems with the upgrade.

 

You have a much larger chance of having issues when upgrading from a very old beta build, than you do just upgrading when new builds come out.

 

Actually, your post just shows that you have a much larger chance of having issues when upgrading and plugins are involved.

 

The issue had nothing to do with the fact that your friend was running an older build.. despite the fact that your upgrade from a newer build with the same plugin went ok. Had he removed all plugins prior to upgrading, he could have been up and running in < 5 minutes.

 

:-)

 

Sent from my SGH-I747M using Tapatalk 4 Beta

 

 

Link to comment

I upgraded from rc12 to 5.0 removed everything including SF and other plugins. I also upgraded the webgui now simplefeatures stats are gone as well. Does it included in the webgui? Or I will have to add those simplefeatures addons? Thanks

 

The official WebGUI isnt finished and will have a stats page at some time.

 

Actually, your post just shows that you have a much larger chance of having issues when upgrading and plugins are involved.

 

The issue had nothing to do with the fact that your friend was running an older build.. despite the fact that your upgrade from a newer build with the same plugin went ok. Had he removed all plugins prior to upgrading, he could have been up and running in < 5 minutes.

 

:-)

 

Sent from my SGH-I747M using Tapatalk 4 Beta

 

I had the exact same plugin versions, same hardware, same shares, same everything when I upgraded and had no issues. Our servers are exact 1:1 copies. I copied my flash drives when setting his up (minus separate licenses), and we sync files weekly. The only difference was he upgraded from a much older beta to 5.0 Final.

 

In our troubleshooting we did roll back to his flash drive backups, upgraded again with zero plugins, then enabled the plugins after everything was OK. Exact same thing happened and that's how we figured out it was a plugin. Up and running, to me, means plugins too. I ultimately just ended up having to reset his plugins and it was a huge headache. I've never had to do that on my servers and I upgrade every time a new version releases... take with it what you will.  ;)

Link to comment

A bug in v5.0-i386:

In the WebGUI I uncheck the "Correct" checkbox, and start a parity check.  The syslog shows:

Aug 30 09:03:49 ToyServ kernel: mdcmd (41): check CORRECT
Aug 30 09:03:49 ToyServ kernel: md: recovery thread woken up ...
Aug 30 09:03:49 ToyServ kernel: md: recovery thread checking parity...

 

My "mileage" did vary.....yesterday I went back to the stock webGUI and did about the same thing as you (unchecked the "Correct" checkbox) and got the correct result as shown in my syslog:

Aug 29 17:05:05 Tower kernel: mdcmd (17): check NOCORRECT (unRAID engine)
Aug 29 17:05:05 Tower kernel: md: recovery thread woken up ... (unRAID engine)
Aug 29 17:05:05 Tower kernel: md: recovery thread checking parity... (unRAID engine)
Aug 29 17:05:05 Tower kernel: md: using 1536k window, over a total of 2930266532 blocks. (unRAID engine)
Aug 29 17:06:48 Tower kernel: mdcmd (18): nocheck  (unRAID engine)
Aug 29 17:06:48 Tower kernel: md: md_do_sync: got signal, exit... (unRAID engine)
Au

I just let it run for a minute or so........

 

 

this bug has already been reported to Tom.

 

first parity check after array start is forced to be correcting regardless of the check box. [bug].

Link to comment

The "1st parity check is always correcting" bug was fixed in RC16c ... but crept back in to v5.0

 

Tom is aware of it (it's been reported) ... I'm sure it will be fixed in the next release.

 

Meanwhile, the workaround is simple:  start a check, then abort it.    After that it works correctly.

 

Link to comment

The "1st parity check is always correcting" bug was fixed in RC16c ... but crept back in to v5.0

 

Tom is aware of it (it's been reported) ... I'm sure it will be fixed in the next release.

 

Meanwhile, the workaround is simple:  start a check, then abort it.    After that it works correctly.

 

Something strange... I did myself reported "1st parity check is always correcting" for rc16, it's posted on issues forum, i.e. the problem was actually present on rc16, but I can't reproduce it myself anymore on final.

 

What exact steps you did to reproduce it?

 

The problem that seems back on 5.0 final is the one after using "Parity is already valid." option... but that's a different one...

 

P.S. I'm using stock gui, not sure if it does any difference.

Link to comment

The "1st parity check is always correcting" bug was fixed in RC16c ... but crept back in to v5.0

 

Tom is aware of it (it's been reported) ... I'm sure it will be fixed in the next release.

 

Meanwhile, the workaround is simple:  start a check, then abort it.    After that it works correctly.

 

Something strange... I did myself reported "1st parity check is always correcting" for rc16, it's posted on issues forum, i.e. the problem was actually present on rc16, but I can't reproduce it myself anymore on final.

 

What exact steps you did to reproduce it?

 

The problem that seems back on 5.0 final is the one after using "Parity is already valid." option... but that's a different one...

 

P.S. I'm using stock gui, not sure if it does any difference.

 

 

I get the correcting 5 errors on the first check everytime like clockwork. Running v5.0, was the same on rc16c.

Link to comment

I am finding two things pretty amazing:

 

1. How few problems are people reported

2. How many people decided to install an RC and then not keep it patched

 

#1 is even more amazing given #2

 

what is so amazing?

I am still running 5.0 Beta 13 (NOTE: BETA) and have been running for 2 years straight.

no issues what so ever

 

If you don't know why I cant explain it to you :)

 

This is exactly why "final" releases matter - major fragmentation within the unRAID "market".

Link to comment

Ther is always fragmentation in any software market. If something works ther is less inclination to do anything to it that might break it.

 

I still have several pc at work running win2k, xp, vista alongside win 7 and 8 . So what do you expect for a nas software.

 

Sent from my SGH-T889 using Tapatalk 4

 

 

Link to comment

Hey all, I just finished the upgrade from v4.7 final --> 5.0 final this morning, and it went off without a hitch. I disabled all the plugins I had first, followed the directions, and it worked like a champ.

 

And, can I just say, having not used any of the v5.0 RC's, and this being my first time seeing v5.0: it is awesome!! I know it took forever, but it really is a big leap from the previous version, and functionality aside, it looks a lot more professional as well. Thanks again for your hard work Tom.

Link to comment

Ther is always fragmentation in any software market.

 

Yes there is, but drawz has a point.  I've said it before, mea culpa for even doing the -rc series, I should have just released 5.0 after last -beta, then we'd be at what, 5.0.27 or something, or 5.x.y?  Live and learn.

Link to comment

Ther is always fragmentation in any software market.

 

Yes there is, but drawz has a point.  I've said it before, mea culpa for even doing the -rc series, I should have just released 5.0 after last -beta, then we'd be at what, 5.0.27 or something, or 5.x.y?  Live and learn.

 

Except then you would have had a "final" out there with a major bug for potential data loss and a lot more likely for people to have hit it.

Link to comment

 

Yes there is, but drawz has a point.  I've said it before, mea culpa for even doing the -rc series, I should have just released 5.0 after last -beta, then we'd be at what, 5.0.27 or something, or 5.x.y?  Live and learn.

 

Tom ----  I really don't' think that the rc series was a mistake by any standard!  If you had release the last beta as  'Final' rather than the rc series, people would have quickly settled on a 'version' that worked for them and not updated as each point issue came out.  They would simply waited using their favorite point version until they thought all of the issues had been solved.  (I believe that most of us went through the beta and rc release cycle because we were looking a really staple final product and willing to test each new release as it came along!)  Now that Ver 5.0 is out and looks to have virtually no problems, most people are going to upgrade to it and use that one.  With this occurring, support will become a much simpler problem. 

 

As I think about it, I feel that the new GUI should be released as a plugin and supported separately.  That might simplify both the development of the core server product and the new GUI with all of its plugins that will be added to utilize more of the computing power of the hardware to serve as a complete media server center.  It also means that people who only want to use unRAID strictly as a server could miss all of the problems that the plugins will introduced that have to be solved. 

Link to comment

 

Yes there is, but drawz has a point.  I've said it before, mea culpa for even doing the -rc series, I should have just released 5.0 after last -beta, then we'd be at what, 5.0.27 or something, or 5.x.y?  Live and learn.

 

Tom ----  I really don't' think that the rc series was a mistake by any standard!  If you had release the last beta as  'Final' rather than the rc series, people would have quickly settled on a 'version' that worked for them and not updated as each point issue came out.  They would simply waited using their favorite point version until they thought all of the issues had been solved.  (I believe that most of us went through the beta and rc release cycle because we were looking a really staple final product and willing to test each new release as it came along!)  Now that Ver 5.0 is out and looks to have virtually no problems, most people are going to upgrade to it and use that one.  With this occurring, support will become a much simpler problem. 

 

As I think about it, I feel that the new GUI should be released as a plugin and supported separately.  That might simplify both the development of the core server product and the new GUI with all of its plugins that will be added to utilize more of the computing power of the hardware to serve as a complete media server center.  It also means that people who only want to use unRAID strictly as a server could miss all of the problems that the plugins will introduced that have to be solved.

 

i speak from experience. when you start having multiple ui's to support (themes/or separate ui plugins) it greatly slows down development since you have to do everything twice.. check everything twice.. troubleshoot bugs twice.. especially since both are coded with different frameworks (jquery or not).

 

ideally a well established framework for the gui is the first step. trying to do a new ui and a plugin thing is a bit much all at once. getting the existing ui options ported over to the new ui should be done first before trying to add new features.

 

Link to comment
Guest
This topic is now closed to further replies.