Your Chance to Chime In

[itimpi]

I think it is perfectly valid to make a 5.0 release with a number of known issues.  This is not at all uncommon in he software world as it is virtually impossible to produce software with no known bugs (particularily ith something like unRAID which uses many third party components). 

 

A lot of people (and I am one of them) are not being affected by these issues.  Simply changing the label to final means that people will be more inclined to believe the release is trustworthy enough to be worth trying.  It is surprising how many people will simply not ven trial software until it is no longer labelled as a beta.  It is also important to have a release that supports 3TB+ disks that is not labelled as a beta release.

 

I would then recommend that work immediately starts on a 5.1 release that is intended primarily as a bug-fix release for those who still encounter problems.  This release should be mentioned as coming in the 5.0 release notes and the rational behind it.  Once that is out of the way then work can start on new roadmap features (e.g. N+1 parity).

[speeding_ant]

The current kernel is working really well, for a lot of people. You've solved the Realtek NIC issues, and you've improved emhttp stability issues. Honestly, that's enough to call it v5 final. I, for one, am really happy with this version.

 

Commercially it would be a smart idea to move to a final version with 3TB support as well.

 

I'd look at a longer plan to move to a 64 bit kernel. You'll start seeing drivers/binaries become 64bit only (or at least more accessible) over the next few years, best you choose a release to start 32/64 bit side by side to get the community testing it. I suspect you won't have too many issues, and you can start phasing out 32 bit support.

 

Keep up the good work, we're loving it.

[S80_UK]

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

 

Indeed we do, although to be fair, many of us already did.

 

Thanks for asking the user community in this way and for offering a voting option on this important topic.

[dave_m]

Release 5.0 and use a 64-bit kernel for the next release (5.1, 6.0...)

 

I think there will be plenty of people happy to upgrade to an "official release" from 4.x, as there have been bug fixes and new hardware supported like LSI cards and 3+ TB drives.  If the 64 bit kernel solves the write problem and is the next priority, then hopefully the X9SCM-F users will be satisfied as well.

[bonienl]

Release a final version 5.0, but mention known issues. This will show progress and give people an educated way of choice.

 

Trying to achieve perfection means you end up in a never ending story.

 

Who guarantees that 64-bit solves *all* problems? The truth is propably in the middle, it will solve some but likely introduces something else...

 

The new features and support for 3+TB disks alone are valid reasons to go for final, and take away the hesitance that people have with something labeled 'beta'. Version 5 does work well for a large group of people...

 

It is perfectly alright to address the known issues in a later release, and perhaps workarounds are found meanwhile.

[JustinAiken]

I don't care if it's called 5.0rc47, 5.0 final, or unRaid Purple - I just want to see something that I see others using successfully that have my same mobo/sata cards... 

 

I've been loving seeing the updates flowing again, keep it goin'

[lionelhutz]

You'll never get a release that works on every possible combination of hardware so you just have to address the issues you can. This doesn't sound like something that can be addressed at this time without major code re-writing and 5.0 is too far along to go back to beta status. So release and fix it when you can.

 

I'd say keep a list of the motherboards that seem to have this issue in the release notes or thread.

[tramco]

For what it is worth, I have been using a licensed version since 5.0-rc1 and have not one problem with it.

 

As you can see from my System Info below, my build is pretty basic running AirVideo, PyTivo, Subsonic and Simplefeatures 1.05.

 

Thanks to limetech (Tom) and the rest of you for making things work for those of us who haven't a clue.

 

[PeterB]

You'll never get a release that works on every possible combination of hardware so you just have to address the issues you can.

 

I agree that no software can ever be perfect, especially a major system/application such as unRAID which is expected to run on innumerable combinations of hardware, but putting out something with the label 'Final' may well silence some of the critics for a while.

 

However, what I would say is that the X9SCM-F is, probably, one of the most popular server-grade boards available for any new system build.  I am/was just on the point of ordering this board for a system upgrade.  I guess that any X9 board is going to be afflicted by the 'slow write' problem - probably anything based on the C204 chipset.

 

I, personally, wouldn't be particularly worried about reverting to a previous rc, but I wouldn't want to expose myself again to the bug which fails to permanently mark a disabled drive.

 

I know that it's undesirable, but would you be amenable to making a separate image available for the X9xxx users which includes all the unRAID fixes, but with the previous kernel?

[Kryspy]

If there aren't any critical bugs; only performance issues then release 5.0 final for sure.  Nothing is 100% in this world.

 

I do agree as many distros such as Linux Mint to name one have had 32 bit support issues lately.  64 bit is where we need to be and even if you're not 100% it will solve the issue it certainly is the road to travel down.

 

Kryspy

[mattw]

Personally, I would like to see it work and it does!  Tom, if you are comfortable enough to call it a final then do so!  I would like to see a 64 bit version at some point, but I am on my first server and I am thrilled with the way it works.  It beats the hell out of my old D-link DNS-343. 

[BobPhoenix]

I'm using a Tyan S5512GM2NR (C204 - equivalent to X9SCM) and if anything I noticed an increase in parity build speeds between RC4 and RC10 in my unRAID VM (3GB assigned to VM) on ESXi 5.0.  I had replaced some drives including parity while using RC4 and got 90+MBs at the start.  Upgraded the unRAID VM to RC10 and got 110+MBs at the approximate same part of the disk - essentially first 2% of the parity build.  Don't have both logs to check the total times so cannot positively confirm that it was faster however.  The array has 14 2TB drives with 6 7200 drives (parity and 5 other drives) and 8 5400 drives all Hitachi.  I will be checking actual write speeds from my Windows box tomorrow but I don't expect any problems.

 

So I think RC10 can go final right now.

[mrow]

I think you should release the current version as final so we can get the hold outs to finally move over. Then start work on moving to the 64 bit kernel. Perhaps in the interim release a version with an older kernel without the slowness issue. But if you keep playing whack-a-mole with bugs you will never get a 5.0 final released.

 

Also as others have said not everyone with the X9SCM is having the slow write issue. I use that board and haven't had any issues.

[PeterB]

Also as others have said not everyone with the X9SCM is having the slow write issue. I use that board and haven't had any issues.

 

How much memory?  It seems that those with slow writes have more than 4GB.

[p.totton]

My vote is to make a 5.0 final now for the following reasons:-

1. It is the right thing to do for support

Limetech needs to encourage its user base away from version 4.7 because it will become increasing difficult to support on software that old, nor will many of the expert users on the forum be using it either.

2. It is the smart thing to do commercially.

Impressions ARE important to your brand and that means being predictable with releases. Software that stays Beta forever looks like hobby software that only unix guiru's should be using. Now I know even the Unraid early beta's were rock solid but try convincing potential new customers about that.

3. Give yourself a breather with the 5.0 final milestone release.

Tom you have already put in blood sweat and tears into this release, you need to take stock, sit back and make sure you fully understand any remaining issues and their impact rather than simply continuing with this RC series.

 

Keep up the great work and the comms

[Suse User]

In my view there is no point in releasing 5.0 Final until the know issues are addressed.  People can already get this version precisely as it is and it won't work any better by changing the version number.

 

The idea that other companies release products they know have issues so it's fine for UnRaid to do the same is just stupid.  If people want this version it's here for them (I'm using it), leave the RC tag in place as it acknowledges theres there are some issues.

 

I think a carefully worded concise announcement that you strongly suggest people move to the latest v5.xRC but acknowledging the known issues would strengthen peoples confidence in your integrity regarding your product over stating it's done when it clearly isn't.

 

We all appreciate the problems your dealing with and the time your spending on finding a solution, but this is peoples data you dealing with, data they feel strongly enough about to want to protect it with a raid solution.  I think the masses (me included) would lose a little confidence if we can't that trust a "Final" version is not just that in name only.  v5 isn't final yet, so why call it that? 

 

Mark. 

[BetaQuasi]

I just wanted to chime in that I have the X9SCM-F in my build, am running RC-10 and have no slow write issues... non-cache drive writes are sitting at 40ish MB/s, which is pretty much spot on with parity.

 

So while it's a little bit biased, I'd be happy for a final now with the known caveat that some people may experience the slow write issue.

[Eisi2005]

Release 5.0 but give an exact instruction to fall back to 4.7. so every people could test 5.0. If it is ok fine, if not people could go back to 4.7

[mejutty]

At what point is a formal HCL going to come into affect??  There is always going to be some piece of hardware that does not work.  IS running in VM officialy supported, is having more than 4gb of ram supported etc etc.  If the slow writes bug can be replicated and a clear harware configuration identified as the cause then someon has to decide if this is big enough to hold out for or officialy say it's not supported due to or provide a work around ie you can use this family or this motherboard so long as only 4gb ram.  Every vendor has an offical HCL and the wiki for 4.7 is full or tested working and non-working hardware, greenleaf has it's blog with tested and recommended builds.  Where do you draw the line.  I guess we can wait we can say go 64 bit but at what delay to releasing 5 final.

 

I say find out exaclty the hardware/config that causes the slow writes and see if there is a workaround ie motherboard type with more than x amount of ram. this provides an working solution as apposed to it not working at all.

 

Save 64bit kernal upgardes for later releases.

[bonienl]

Release 5.0 but give an exact instruction to fall back to 4.7. so every people could test 5.0. If it is ok fine, if not people could go back to 4.7

For a lot of people version 4.7 is not an option anymore...

 

[PeterB]

I have the X9SCM-F in my build, am running RC-10 and have no slow write issues...

 

Perhaps you would like to post your hardware configuration in the X9SCM thread, so that the problem can be categorised.

[nars]

I could see 2 or 3 guys that posted saying that have that x9scm and no write performance issue (excl. BetaQuasi as he is probably using unraid on esxi not native)... would be interesting that users with that specific MB compare whole hardware specs and bios settings to try to get some conclusion.

 

Concerning release v5 or not, IMO this must be only a Tom decision as... we are fully aware of the situation, we have the version available, and we can use it or not, doesn't matter how it is labeled... and it's Tom that may "suffer" with the release getting support issues... on the other hand 4.7 is also far from perfect version from what I could read (never used it myself)... then...

 

I would say maybe wait just a bit more (1 week, 2 weeks... after so much time the v5 is pending it would not hurt...) and see if users with that motherboard can get to some conclusion... or even any chance you Tom could get such MB and check it? Else if the conclusion it's just it is really kernel related and no fix comes up then release it... else v5 will be rc forever... then look at building x64 kernel, etc... anyway I guess you will either continue maintaining both 32 and 64 bit flavors (as some users may still have old non 64bit capable hardware) or just leave current v5 as latest 32 bit capable version (if you don't plan to always release both)? in either case you will need to call the 32 bit flavor final even including this issue.

 

p.s. Tom: if you release v5 don't forget the ftp thing   (not sure if you did see my 2nd post about leave only root access and a possible good vsftpd config following some tests I made)

[madshi]

IMHO the most important thing about 5.0 is the support for bigger harddisks. That's a key feature for me. So delaying it much further would be bad. So my opinion is to make 5.0 as stable as possible, and then release it. So fix all stability issues and important bugs (other than speed) and then release it. If it has slower write speeds for some users that's unfortunate, but every user can choose which version to install. So if write speed is key for some users they can stick with older/other builds. There most definitely is a need for a stable "release" build with support for bigger harddisks. I've been waiting many many months for this, and I don't feel like using beta builds. I can live with slower write speeds for a while...

[jaybee]

I voted to release it. The main reason is that we have still had no statement about fixing 4.7 issues. I assume Tom, that these will not be fixed as your efforts are focused on getting 5 FINAL as priority. There is currently to my eyes no official FINAL stable version out there. Version 5 FINAL needs to happen asap, even if it means compromising a little.

 

Of the options presented, I agree a 64bit kernel is the ongoing route I would like to see, but this is not something to be doing now just because a few users have mentioned a slow write bug. With this thinking, 5 would never go final. There will always be something. Catering for so much hardware is your own worst enemy sometimes. I think you need to be more ruthless and state that XYZ ONLY are supported if need be. i.e. If it were me, I would have just given up realtek NIC support ages ago and said to people only Intel NICs are supported. I say that as someone that owns a board with a realtek on board NIC, but would quite happily pay and install an Intel one knowing they cause a lot less issues and are better performance typically anyway.

 

It looks like the "write bug" only seems to affect some people anyway, and as said, people with larger amounts of ram (over 4gb). If this really is the only major bug - and all other minor ones mentioned are indeed fixed like you said they will be for FINAL - then I think the time is now. 4.7 has bugs and lack of support for modern drives. We need a release ASAP. That's the bottom line.

 

I appreciate the hard work you have put into this by the way.

 

What ever your decision going forward with 5.1/6.0 or whatever, we need some kind of road map or prediction of ETAs and/or a promise of what communication updates we will get to state progress. I would support testing a 64bit kernel if I could facilitate it.

 

Thanks

 

 

[cfmjohn]

I guess this will be unpopular but I voted for delaying the release.

 

I've been on 4.7 for a year now and I'm perfectly happy with it. My uptime has been over 6 months because I use my unraid for one thing - storage. I run a separate server with sab etc. If the reason for the slow write speeds isn't known it makes no sense to release it. Its a disaster waiting to happen - what if it's having an effect that's not been found yet.

 

Final software should be in a state that its ready to work. Bugs discovered after release is one thing but releasing with a known problem - seems odd.

 

I know everyone's keen to get a new version. I'm really looking forward to it too but I really don't and won't trust beta/RC software with my data.