Your Chance to Chime In


limetech

Recommended Posts

Everyone asks, "When the hell is 5.0 final going to be released?"  (among other queries)

 

Now we're at a good point to bring up the kinds of issues that have prevented this.

 

The current state of the code is this.  It seems to work fine for a 5.0 release.  Some rough edges, some more functionality to add/change, but all-in-all I think it's good to go except for the "slow write" issue being hashed out in this thread:

http://lime-technology.com/forum/index.php?topic=22675.0

 

This issue affects a small percentage of the total user base, but a growing one, because this is happening with newer h/w (to best of my knowledge).  What will happen though, is if 5.0 becomes "final" a much larger percentage of users will start upgrading and this issue will surely come up and I'll get pounded on, "WTF, my transfer speeds suck with this release!"

 

Here are some possibilities for fixing this:

a) regress to a kernel that doesn't have this problem (but might break something else)

b) wait for kernel guy to fix this issue and then for maintainer to roll fix into 3.4.x

c) fiddle around with VM settings until it's acceptable (no guarantee this will work)

d) provide a 64-bit kernel

e) something else?

 

The best solution IMHO is choice d).  However, this might take a while and introduce other issues.

 

So now you see my dilemma.  This sort of thing is what has prevented me from releasing a "final".

Link to comment
  • Replies 301
  • Created
  • Last Reply

Top Posters In This Topic

We need to get a 5.0 release out sooner rather than later.

 

I understand you are going to have people doing a "WTF, write speed is so slow" but unRAID is much more of a write once read many setup.

 

So long as the first thing figured out for 5.1 is the write slowdown I say release 5.0 and go from there.

Link to comment

The best solution IMHO is choice d).  However, this might take a while and introduce other issues.

If that is the best solution and will solve the problems, go for it. But keep your users posted about the progress, and come up with a good planning, e.g. the 64 bit version will be released in Q2 etc.

 

If not, you release a v5 version that has known issues, and you start working on a version 6.0 that will be built on a 64 bit kernel anyway... so better get it over with.

Link to comment

I really think 5.0 final should be released now as it seems to be an impossible task to make it compatible with all hardware and to satisfy all users. The continual change of kernels and chasing the perfect version can only mean that 5.0 final will never be released and to be honest I am fed up of checking this site to see if 5.0 has gone final. Release 5.0 now - Please!

Link to comment

If that is the best solution and will solve the problems, go for it. But keep your users posted about the progress, and come up with a good planning, e.g. the 64 bit version will be released in Q2 etc.

 

I agree.  Tom, I know you're not an update whore, but a bi-weekly status update would be very welcome.  Even if all it says is "still grinding away on the ________ bug/issue"

 

I'm not affect by this issue but i think moving to a 64bit kernel is probably a good thing to do.  Either way might as well push 5.0 out and shut everyone up and then us bleeding edge types (read: awesome) can help you test 5.1 x64 ;)

Link to comment

If that is the best solution and will solve the problems, go for it. But keep your users posted about the progress, and come up with a good planning, e.g. the 64 bit version will be released in Q2 etc.

 

I agree.  Tom, I know you're not an update whore, but a bi-weekly status update would be very welcome.

 

 

 

I really don't think this would work. We have been promised more frequent updates but they never happen. Either accept 5.0 now or we will have more periods of no communication and arguing between users/customers like we have had in the last 3 months.

Link to comment

What is the difference between RC10 and final 5 if there are known issues and disclaimer of performance issues.

Why release a final 5 in this state? Just for saying there is a final 5?

Will someone with 4.7 upgrade to such a final 5 version at all? All others who are already using v5 RCs will probably upgrade to RC10 and on at some point anyway (including me RC8a).

 

How fast do you expect you can turn out a x64 kernel version? maybe it is worth the wait? Are you sure this will fix the performance issue?

Link to comment

That is a pretty popular motherboard. It's a perfect unRAID server class motherboard.

 

typing frankly... I think it is wise to try to get that board working. It's reliable, popular, cost effective.

I was planning to upgrade to that board myself since it's a nice board.

 

Does it have anything to do with either of the Ethernet ports? Perhaps switching or perhaps an IPMI interference?

 

If write speed directly to a drive via the writeread10gb shell is good, then it's a networking issue.

 

Granted, I have not read the whole thread, but since that's a popular board, it might be worth the expense of purchasing it and getting it to work well.

 

I would suggest no new features, but refining what is there to work with the current popular hardware is wise.

 

Also, if you really believe that 64bit would solve the slow write issue, then go down that road.

 

If you think c) could actually work, try it.

 

Ultimately you want to be at d) ,  yet what's your confidence of getting it working in a reasonable time frame.

frankly, I don't know if you want to introduce such a massive change while finalizing a release.

 

Is releasing production grade software, knowing that it does not work well in certain conditions the right way to go?

Link to comment

If that is the best solution and will solve the problems, go for it. But keep your users posted about the progress, and come up with a good planning, e.g. the 64 bit version will be released in Q2 etc.

 

I agree.  Tom, I know you're not an update whore, but a bi-weekly status update would be very welcome.

 

 

 

I really don't think this would work. We have been promised more frequent updates but they never happen. Either accept 5.0 now or we will have more periods of no communication and arguing between users/customers like we have had in the last 3 months.

Please don't make this a "bitch about Tom" thread.

Link to comment

What is the difference between RC10 and final 5 if there are known issues and disclaimer of performance issues.

Why release a final 5 in this state? Just for saying there is a final 5?

Will someone with 4.7 upgrade to such a final 5 version at all? All others who are already using v5 RCs will probably upgrade to RC10 and on at some point anyway (including me RC8a).

 

How fast do you expect you can turn out a x64 kernel version? maybe it is worth the wait? Are you sure this will fix the performance issue?

 

I really can't believe this, virtually everyone has been complaining about the lack of communication and the failure to release 5.0 and now you are saying delay it?

 

If there is no difference between RC 10.0 and and final 5.0 then what's the difference between final 5 and numerous RC 6.xxxx

Link to comment

If that is the best solution and will solve the problems, go for it. But keep your users posted about the progress, and come up with a good planning, e.g. the 64 bit version will be released in Q2 etc.

 

I agree.  Tom, I know you're not an update whore, but a bi-weekly status update would be very welcome.

 

 

 

I really don't think this would work. We have been promised more frequent updates but they never happen. Either accept 5.0 now or we will have more periods of no communication and arguing between users/customers like we have had in the last 3 months.

Please don't make this a "bitch about Tom" thread.

 

Tom, that was not my intent. I am just trying to avoid what has happened in the last few months. If you release 5.0 now + the minor fixes that you have mentioned then quite a few of us can just move on and use the software as intended.

Link to comment

Personally I'm somewhere in the middle on this whole issue. On the one hand I am desperate to move to 5.0  from 4.7 to take advantage of the 3tb+ drives but but on the other hand this is my only server I am not confident enough to upgrade and risk something going wrong.

 

I think it would be sensible to keep this in the rc stage for now. How can something be labeled final and stable when there are known issues. Like the other poster said, the people who are willing to play with the rc versions will no doubt upgrade to future rc releases to test things and those who need the piece of mind will be happier to wait rather than upgrade to a final that kicks up problems.

 

In short my vote is wait for final.

Link to comment

I really can't believe this, virtually everyone has been complaining about the lack of communication and the failure to release 5.0 and now you are saying delay it?

 

If there is now difference between RC 10.0 and and final 5.0 then what's the difference between final 5 and numerous RC 6.xxxx

 

I think most of the complaining was for lack of communications about a promised final 5 anf not a final 5 itself.

 

If you are calling to immediately release a final 5 - then I suspect RC10 will just be renamed final 5.

What is that good for? What will it give you? More confidence to use it?

 

Link to comment

I would go with the current 32 bit release for 5.0.  I am no guru here, but I feel that going to 64 bit could introduce a bunch of other uncertainties (think Realtek for a start, and what about the various SATA PCI-e cards?).  5.0-RC10 seems very solid for those who are getting satisfactory write speeds, myself among them.  Getting any new release "out-there" will always generate some WTF? type feedback.  (In my day job I approve firmware releases and updates for internet connected consumer devices, so I have seen a few. ::) )  On the plus side, more users seeing the slow writes problem would give a greater level of knowledge on which hardware/software combinations the issue may be seen.  That will allow advice, warnings and disclaimers to be updated in the short term and could allow a cleaner and perhaps more successful fix when eventually released, perhaps as version 5.1

 

Another angle is that there seems to be a core of users who hang on to 4.7 just because they need to see the word "final" somewhere before they will upgrade.  They are facing other issues, especially the 2TB drive size limitation, and a little uncertainty regarding the known issues within 4.7 that are completely addressed with version 5.  I think getting a version 5 final released could help the user base more than it hinders.

Link to comment

My two cents.  I say release 5.0 with a list of the Motherboard(s) with the issue.  This will get Version 5 out and allow most users to move forward.  (Many people insist  that they will not use beta software.  Personally, I consider most X.0 software releases to be betas but, with all of the testing and rc's, I consider this 5.0 release to be at least 5.09!    ::)  ) 

 

Then work to resolve the problem.  My recommendation would be to change unRAID to use the 64 bit kernel.  This will put the unRAID  in the main stream of Linux kernels as I  suspect that the 32bit version is going to continue to suffer from lack of support.  Who else is using a 32 bit kernel on a cutting edge, state-of-art motherboard?

Link to comment

 

What is that good for? What will it give you? More confidence to use it?

 

Quite frankly, yes it will. No more beta warning screens when starting for a start.

 

The users who want all of the issues fixed surely would not have any issues with the current version being relased as 5.0 final and a new version with all issues fixed released as 6.0?

Link to comment

 

Is it only that one SM MB that is affected?

 

Is it worthwhile putting together a compatibility list of MB's that have tested flawlessly?

 

I didn't read through that whole 12 page thread, but I did think SM was supposed to have pretty good support.  Especially if they are getting bad press about it being one of the few boards that don't work right, and a number of people here hammering on them all at once looking for help to get their board working right.

Link to comment

How can something be labeled final and stable when there are known issues.

 

Most of the software that you use will fall into that category.  On the hardware side, very many of the CPUs, Northbridge and Southbridge controllers, mobile phone chips, that you use will also have known bugs and will be sold with the bugs documented.  Software and hardware is often labelled as final because there is a need to get products into the market so that the manufacturer can recoup their investment.  If they wait till everything is perfect, the market will have moved on and they will go out of business.

Link to comment

Release v5.0.

 

As others have stated, no software is perfect, what is important (and what most of the conversation over the last couple months has focused on) is progress. So long as we get regular updates on progress and RCs, everyone is happy.

 

Moving to 64 bit or reverting to a prior kernel may fix some bugs, but is almost guaranteed to introduce others.

 

"Baby Steps"

 

Ost.

Link to comment

Without trying to be smart or making it a bitch session, I don't think it matters which option you choose as long as there is a steady stream of communication updating the paying customers of what's happening.

 

You're obviously working to address to address the known issue while the current RC10 caters for most people so it doesn't really matter what it is called as long as those affected by the bug know how that's progressing.

Link to comment

Everyone asks, "When the hell is 5.0 final going to be released?"  (among other queries)

 

Now we're at a good point to bring up the kinds of issues that have prevented this.

 

The current state of the code is this.  It seems to work fine for a 5.0 release.  Some rough edges, some more functionality to add/change, but all-in-all I think it's good to go except for the "slow write" issue being hashed out in this thread:

http://lime-technology.com/forum/index.php?topic=22675.0

 

This issue affects a small percentage of the total user base, but a growing one, because this is happening with newer h/w (to best of my knowledge).  What will happen though, is if 5.0 becomes "final" a much larger percentage of users will start upgrading and this issue will surely come up and I'll get pounded on, "WTF, my transfer speeds suck with this release!"

 

Here are some possibilities for fixing this:

a) regress to a kernel that doesn't have this problem (but might break something else)

b) wait for kernel guy to fix this issue and then for maintainer to roll fix into 3.4.x

c) fiddle around with VM settings until it's acceptable (no guarantee this will work)

d) provide a 64-bit kernel

e) something else?

 

The best solution IMHO is choice d).  However, this might take a while and introduce other issues.

 

So now you see my dilemma.  This sort of thing is what has prevented me from releasing a "final".

 

Hi Tom,

 

I have been using 4.7 on my old rig for just over 2 years.

 

I built it as a copy of your default build at the time (Supermicro C2SEE), using parts available to Australia.

 

I would love to see a 5.0 final for the following reasons:

1) Support for 3Tb drives

This is important as the drives are cost effective, and it will eliminate expensive upgrade path (bigger PSU, bigger case, additional SATA = >$300)

 

2) Updated SMB (v2)

There have been considerable updates to SMB on Windows clients (eg Win8), but also from my media players (Openelec). Newer SMB support should mean faster read performance.

 

3) Chasing your tail

It seems that unRaid development has been chasing its tail for a while now. Upgrade the kernal to support x... then y breaks. This could go on forever.

 

4) Could you please summarise the "Slow write" issue? I started reading the 12 page thread, but it might be easier for everyone if it was easily quantified about who might be effected.

 

I would be happy to see V5, then see v5.1beta's with experimental kernals for those with performance issues or who would like to be on the bleeding edge.

 

Regards,

Kortina

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.