Your Chance to Chime In

[PeteAron]

 

 

I may be new to this forum, but my computer experience dates back to the 70's.  Absolute agree with your two suggestions. 

 

Yes there needs to be an HCL.  32 bit has limitations - a native 4GB address space.  Can it be made to access memory above that space?  Of course.  Will it work with all hardware?  No guarantees, unless you have the resources of an Apple, Microsoft or HP. 

 

I am amazed by the number of people on this forum trying to add every application under the sun to unRAID.  This is just plain silly.  Just because you can does not mean you should.

 

unRAID was not designed for this.  If want to do this, you are on your own.  If you need application XYZ, put it on a separate box or build an ESXi box and put it in a VM.  Then you can do whatever pleases you without impacting unRAID.

 

Tom,  leave 5.0 as the last 32 bit unRAID.  Yes, you may have 5.x releases to fix problems or add some new features. 

 

Make 6.x 64 bit only.  Put the bulk of your time and effort into making 6.x the unRAID for the future.

 

Well thought out and well said.  I agree with this approach as well.

 

I also agree with Kevlar, I would be willing to pay an upgrade fee for 6.0 w/ a 64 bit OS.  I was thinking about purchasing a second license anyway for a second server.

[tr0910]

Tom,  leave 5.0 as the last 32 bit unRAID.  Yes, you may have 5.x releases to fix problems or add some new features. 

 

Make 6.x 64 bit only.  Put the bulk of your time and effort into making 6.x the unRAID for the future.

 

I agree, call it final.  I have the same SM X9SC-F-O without any issues.  I have a i3 2100 and only 4GB of RAM.  Solid as a rock for me with 2-m1015 and 1 - MV8 on Antec 620C inside a Norco 4224 i3 X9SCM-F-O, feeding a bunch of 2 and 3tb drives

[aiden]

I think most points have been made, for whatever side of the fence you're on. But as a fellow developer, I'm acutely aware of the fact that software is never complete. There is never a "final" version, no matter how much work you put into it. This is a moving, changing landscape of new drivers, new applications, and new bugs. My suggestion is to move the development out of beta if you're convinced the code is stable. That is the key here. As long as we can be assured against data loss via bad code, then moving to production makes sense if all the core elements are as reliable as the 4.x series.

 

Most of us are accustomed to slow write speeds - it's a "feature" of unRAID . My $0.02.

[jbartlett]

Minor humor break - there is such a thing as a bug free program that does exactly as it is intended to do with no chance of any untended quirks.  Here it is in the BASIC programming language.

 

10 END

[stlava]

First time poster. I've just been scouting out the unraid forum over the last week or so waiting for my hardware to arrive (hopefully today) but I wanted to chime in. I read through all of the previous responses and I have to agree with the majority of the posters. It makes more sense to release the current RC as final version of 5.0. Then fork it and begin on a feature release branch 6.x and a 5.x branch for bug fixes only. From experience staying in RC will most likely introduce feature creep.

 

The next issue becomes how to fix the slow write speeds. It seems the issues is affecting a large enough user base that it does need to be resolved. Switching to a 64-bit kernel is probably not the way to go if you want to solve the issue quickly. The best thing is waiting for the kernel people to fix it while fiddling around to see if the issue can be circumvented. I would consider switching to a 64-bit kernel a more long term solution for other things as that's the next logical direction for unraid in general.

[Helmonder]

I agree that the 64bit option is the best one, actually, it is the only one.. The rest are workarounds at best.

 

So my take would be that the best thing to do is have very clear communication:

 

1) Make this release the final V5 and report that there is a kernel bug that will give slow transfer speeds, most likely with new hardware and most likely with more then 4gigs of memory;

 

2) Start work on the 64bit version.

 

How much I would like it for my own situation, reverting back to a previous kernel version will introduce other issues and going back is not a good thing. However unfortunate, the copy speeds are not breaking anything, they are just annoying to extremely annoying (and in some situations, based on what you do with the system) possibly unworkable. "Unworkables" would need to use 4.7 or take their chance with an old RC5 version.

[Helmonder]

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.

 

You are running VM's, the unraid VM probably has less then 4gig assigned to it. Right ?

[WeeboTech]

There may be some good news from the other thread by using the mem=4095 inside the syslinux.cfg.

See here -> http://lime-technology.com/forum/index.php?topic=22675.msg220309#msg220309

 

For those having the slow X9SCM-F issue, please review the thread and test. If this is a successful work around, I will be pro release 5.0 final. Not that my one vote counts that much. (grin).

[StevenD]

There may be some good news from the other thread by using the mem=4096 inside the syslinux.cfg.

See here -> http://lime-technology.com/forum/index.php?topic=22675.msg220309#msg220309

 

For those having the slow X9SCM-F issue, please review the thread and test. If this is a successful work around, I will be pro release 5.0 final. Not that my one vote counts that much. (grin).

 

That should say mem=4095M.  I got an error (of course, I dont remember it), with 4096M.

 

Funny though.... top is only reporting 3GB.

[RokleM]

Funny though.... top is only reporting 3GB.

3gb is common barrier in winderz, not sure if this somehow is hitting unraid too.  I will check mine when I get home.

http://en.wikipedia.org/wiki/3_GB_barrier

[Dephcon]

Mem:   3942540k total

[peter_sm]

2) Start work on the 64bit version.

I like to see RC10 as final, and start a new beta for 64bit

 

//Peter

[dheg]

my two cents:

 

if the only thing that will change is the name, leave it as rc10.

 

Newcomers, as someone else suggested, will look for the latest stable and won't read (I usually don't) any disclaimers. Customer base will not grow on "defective" products.

One they get "unraided" they will get in the forums and see that there is a 5rc10 than long time users are using with some potential issue.

 

Just start working in the 64bit version, before it's too late...

 

On the other hand, I have the X9SCM-F board, and either don't have it nor know about this issue. However, my proposal is to gather all users of this board and collaborate on test/trial to find a solution.

 

[Biggen]

I'm brand new to the Unraid game and am just now getting the parts to build my server.  One of the big reasons I have waited to purchase your software is because of 4.7's inability to use hard drives larger than 2TB.  If you feel the only real problem with 5.0 is the slow writing issue that only is happening to a fraction of your users, then I would say its time to release it.  Those bugs can be worked out later...

 

Please don't wait to release 5.0 until the 64-bit kernel is ready.  That could be added in to a 5.1, 5.2, etc...

[patm95]

I am leaning towards marking the current release candidate as final and deal with the slow write issues in 5.1.  I read a post earlier that pondered if we could get a list of MBs that worked well or didn't with 5.0.  This would be nice as it could give some an idea if they want to make the jump or wait for 5.1.

[pantner]

Ok, had a quick look at the other thread...

 

from what i can gather, the slow write issue is after a combination of the C204 chipset and using over 4GB of RAM, correct?

 

If that is the case, i would suggest 1 change to 5-RC10 before making it 'final'.

Give the user an easy way to limit the RAM if they have this problem. A token file in the Boot/flash folder, a tickbox/dropdown box in the webui, a command in the Go file, etc, etc

 

Make that feature well documented/advertised that if you experiance this issue, lower the RAM using it.

 

Once that is done you can start working towards the 64-bit version while making bug-fixes and adding features to the 5.1 Beta/RC, etc

[nars]

From what I can read some few posts I think there are some people (not many) probably getting a bit scared by reading this topic and thinking that Tom may release a broken version of unRaid as final just due to pressure put on him... the thing is not exactly like that... unRaid seems stable, from what I can understand Tom made small changes on latest RC's, other than fix small bug's that can't be related with "the problem", also updated samba and fuse (minor versions that should only also fix bugs on these and can't be related to "the problem" either) and... new linux kernel version (3.4.x vs 3.0.x) included, for some good reason Tom had to upgrade it, and downgrading will almost for sure cause other problems with other users.

 

The new Linux kernel version included is not some "crap" alpha/beta/whatever kernel... it's a kernel released by "Linux guys" as being "stable", any other Linux distro could be released with it (could also be a good test if anyone with that MB could test a distro with similar kernel, x86 flavor and see if same problem just to be absolute sure it is not unraid specific problem, then test x64 flavor and see what happens)... there is apparently an issue with that kernel and a specific motherboard, and apparently not even on all users with that motherboard (there is an unconfirmed suspicion that maybe only users with >4GB ram? some specific bios settings?). What if the issue is (let's suppose) related to a bios bug, on that specific motherboard, that only happens with >4GB ram and with something new that is actually properly implemented on the new kernel? (and that being correctly implemented then it may NEVER be fixed/reversed/workarounded)? will unRaid release be delayed and wait forever for kernel to be "fixed"? problem may not happen on x64 kernel, as memory is handled by other ways, etc... and users with >4GB will usually use x64 kernel anyway on major Linux distros, then one more reason that no one may care about fixing/workarounding the problem on kernel (or on BIOS if a bug on it). I know this is just a supposition, anyway it may be the case and then it may not make sense to just sit and wait kernel guys to sort the issue, problem needs if possible to be identified with more tests etc, if no conclusion and not anyone else with other hardware have same problem then I think there is only one thing to do... release it and look for another solution for these users with the problem, possible start working on x64 version, but... a x86 version is also needed to be released anyway (there are most probably still users with some non x64 machines, p4's etc) and there is no reason to only release the current x86 when there is also a x64 version available... right?

 

[mrow]

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.

 

8GB.

[StevenD]

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.

 

8GB.

 

Are you running standalone or on top of VMWare?

[Ostrich]

I think the verdict is fairly obvious, now the question for Tom is "when can we get it"

 

Ost.

[mrow]

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.

 

8GB.

 

Are you running standalone or on top of VMWare?

 

Standalone.

[unevent]

Release rc10 as final.  Include known issues in the release notes for those that can read so they will understand the limitations with certain hardware.  There will always be a small subset of hardware that doesn't work without issue and will need to be worked on.  The problem with write speed is not isolated to the unRaid group so it will get more love from the larger audience and will have to roll the fix in when the kernel is updated.  The write issue is not a Tom issue or an unRaid issue, it is a Linux issue so there is not much you can do about it anyway by holding final.  Post a a bug report to Linus and move on.  Moving to 64-bit kernel would be the next logical course for unraid, in my opinion.

 

[Dephcon]

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.

 

8GB.

 

Are you running standalone or on top of VMWare?

 

Standalone.

 

can unraid even address more than 4GB of memory?

[WeeboTech]

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.

 

8GB.

 

Are you running standalone or on top of VMWare?

 

Standalone.

 

can unraid even address more than 4GB of memory?

Yes, but only in with PAE.  Comes mostly in play for the buffer cache.

 

[WeeboTech]

 

Since many of the people complaining about low speed writes have had success with the mem=4095 parameter, I think you can release RC10 as final. You may need to document what's needed if people start having performance issues. Maybe update the syslinux.cfg in the .zip archive to have an additional configuration setting with unRAID (4GB Limit).

 

 

Since I can't change my vote, ill publicly advocate the RC10 to final.