Your Chance to Chime In


limetech

Recommended Posts

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.

 

But what if bugs are just hardware, how many pieces of harware don't work with 4.7 and they are not classed as bugs??  Final software does need to be in a ready state but with solutions that involve an operating system there has to be some sort of HCL in an ideal work it would work with everything but we have to be real.

Link to comment
  • Replies 301
  • Created
  • Last Reply

Top Posters In This Topic

I am pretty new to UnRaid.  I mainly use it for storage and streaming.  However, I think that one of the issues with UnRaid is that it will never work for everyone due to hardware conflicts.  In my opinion, I think UnRaid should be finalized with specific hardware in mind because it will be practically impossible to "tailor" UnRaid in order to acommodate everyone's hardware to work 100%.

 

I would say to make a new recommended hardware list so people will know what works with UnRaid, and what doesn't.

 

 

Again this is just my opinion.

Link to comment

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

 

I've only skimmed the other thread..

 

Do you *know* what the problem is and it's in the kernel?

 

is it a problem with the unraid code and how it interfaces with the code?

 

Or is it just a hope that a new kernel will fix this eventually?

 

e) something else?

 

I've flippantly suggested this before on other threads but if I were in your shoes I would be inclined to seriously think about :

 

- Start restricting and / or publishing an HCL. You can make this as wide or as narrow as you want. Ensure unraid works with that hardware and publish that for anything else we're on our own. I think this used to be quite common with 4.x but has become much more vague with 5 due to the explosion in kernel device support and we users all picking up myriad HBA's and having ever more exotic environments.

 

- Stop distributing unraid as a complete OS. Rewrite it to be neatly installable and buildable (kernel module, emhttp, user shares etc) on a known 'supported' distribution(s). For example CentOS (as an example of a reasonably stable, slow moving RHEL clone). This leaves you free to concentrate on developing core unraid functionality (instead of spending time on the ecosystem as a whole) and let the community worry about bolting bits on via centos. In effect we're already bolting bits on anyway (and in some cases replicating what you've already done..e.g the recent spate of community samba bumps!) so not much would change except it might become easier for us! You're already having hardware support issues  and passing the problem off as being in the kernel so you may as well just hand the whole thing over to a distribution. Unraid seems to be stuck in a grey area of what it wants to be here. It wants to be a complete out the box OS I think. But it's not - it needs a whole bunch of the community addons to actually bring functionality that would be expected from a product of this type. And there seems to be an official stance that so long as a community addon exists it doesn't need to become core (preclear? shutdown?) but at the same time there is the line that anything bolted on is unofficial and not supported. It can be confusing.

 

In absence of all else just label it as final and shove it out the door. As long as everyone is comfortable there is no data loss issue then performance issues (I think?) on some hardware platforms is what it is. Unless *you* can directly fix it there isn't much to be done.

 

My two suggestions above are quite radical and would mean a big departure from how things are currently done. And would no doubt bring their own problems but I would urge them not to be dismissed out of hand. Many other companies / vendors make similar models work so it is possible.

Link to comment

My suggestion :

 

Release a final 5.0 now. Make it more stable by ONLY adding bugfixes to it : 5.1, 5.2, 5.3, ... NO new features or new hardware, ONLY bugfixes!!!

 

Make a separate 5.0F version (F from Features) with new features and support for new hardware (that MB with slow write speads would not be supported in 5.0). Those who want, can run 5.xF on their server to test the new features. While working on 5.xF, don't neglect to add bugfixes to 5.x

 

At a certain point in time. 5.x will be quite stable and 5.xF will have several new features/hardware that should have been tested a lot. At that moment, turn 5.xF into 6.0 and start the cycle again. In 6.x the new features introduced in 5.xF will again become more and more stable.

 

People wanting a stable release go for 5.x and can move to 6.x once they feel 6.x is stable enough (starting from 6.4/6.5/...). People who want some new features (or need them due to hardware support) have to go with 5.xF, 6.xF, ...

Link to comment

My suggestion :

 

Release a final 5.0 now. Make it more stable by ONLY adding bugfixes to it : 5.1, 5.2, 5.3, ... NO new features or new hardware, ONLY bugfixes!!!

 

Make a separate 5.0F version (F from Features) with new features and support for new hardware (that MB with slow write speads would not be supported in 5.0). Those who want, can run 5.xF on their server to test the new features. While working on 5.xF, don't neglect to add bugfixes to 5.x

 

At a certain point in time. 5.x will be quite stable and 5.xF will have several new features/hardware that should have been tested a lot. At that moment, turn 5.xF into 6.0 and start the cycle again. In 6.x the new features introduced in 5.xF will again become more and more stable.

 

People wanting a stable release go for 5.x and can move to 6.x once they feel 6.x is stable enough (starting from 6.4/6.5/...). People who want some new features (or need them due to hardware support) have to go with 5.xF, 6.xF, ...

 

+1

Link to comment

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.

 

How can I test for that slow-write issue? Is it copying files from one disk to the other or from a Windows PC over the network to the unraid server? Config is in my sig.

Link to comment

I am new to unRAID (in fact, still building my server, should be online within a month or two).

 

However, reading through the forums for the past few months, I'd by happy with and am looking to go straight to v. 5 (whether that's as an RC or as a final release). 

Link to comment

My suggestion :

 

Release a final 5.0 now. Make it more stable by ONLY adding bugfixes to it : 5.1, 5.2, 5.3, ... NO new features or new hardware, ONLY bugfixes!!!

 

Make a separate 5.0F version (F from Features) with new features and support for new hardware (that MB with slow write speads would not be supported in 5.0). Those who want, can run 5.xF on their server to test the new features. While working on 5.xF, don't neglect to add bugfixes to 5.x

 

At a certain point in time. 5.x will be quite stable and 5.xF will have several new features/hardware that should have been tested a lot. At that moment, turn 5.xF into 6.0 and start the cycle again. In 6.x the new features introduced in 5.xF will again become more and more stable.

 

People wanting a stable release go for 5.x and can move to 6.x once they feel 6.x is stable enough (starting from 6.4/6.5/...). People who want some new features (or need them due to hardware support) have to go with 5.xF, 6.xF, ...

 

What you just described is basically the "Stable" and "Beta" model just with different names.  But worse, he would still need a beta version for both the bugifxes in Stable as well as while testing the new features in "F" (aka beta .. .so a beta to a beta which is [drum roll] "Alpha")

 

That just sounds like a recipie for pain and confusion.

Link to comment

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

 

I've only skimmed the other thread..

 

Do you *know* what the problem is and it's in the kernel?

 

is it a problem with the unraid code and how it interfaces with the code?

 

Or is it just a hope that a new kernel will fix this eventually?

 

e) something else?

 

I've flippantly suggested this before on other threads but if I were in your shoes I would be inclined to seriously think about :

 

- Start restricting and / or publishing an HCL. You can make this as wide or as narrow as you want. Ensure unraid works with that hardware and publish that for anything else we're on our own. I think this used to be quite common with 4.x but has become much more vague with 5 due to the explosion in kernel device support and we users all picking up myriad HBA's and having ever more exotic environments.

 

- Stop distributing unraid as a complete OS. Rewrite it to be neatly installable and buildable (kernel module, emhttp, user shares etc) on a known 'supported' distribution(s). For example CentOS (as an example of a reasonably stable, slow moving RHEL clone). This leaves you free to concentrate on developing core unraid functionality (instead of spending time on the ecosystem as a whole) and let the community worry about bolting bits on via centos. In effect we're already bolting bits on anyway (and in some cases replicating what you've already done..e.g the recent spate of community samba bumps!) so not much would change except it might become easier for us! You're already having hardware support issues  and passing the problem off as being in the kernel so you may as well just hand the whole thing over to a distribution. Unraid seems to be stuck in a grey area of what it wants to be here. It wants to be a complete out the box OS I think. But it's not - it needs a whole bunch of the community addons to actually bring functionality that would be expected from a product of this type. And there seems to be an official stance that so long as a community addon exists it doesn't need to become core (preclear? shutdown?) but at the same time there is the line that anything bolted on is unofficial and not supported. It can be confusing.

 

In absence of all else just label it as final and shove it out the door. As long as everyone is comfortable there is no data loss issue then performance issues (I think?) on some hardware platforms is what it is. Unless *you* can directly fix it there isn't much to be done.

 

My two suggestions above are quite radical and would mean a big departure from how things are currently done. And would no doubt bring their own problems but I would urge them not to be dismissed out of hand. Many other companies / vendors make similar models work so it is possible.

 

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.

Link to comment

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.

 

+1

Link to comment

A 64-bit kernel is a huge change so there's no point in waiting (I'd expect it to be in beta for months).

 

I'm a sucker for upgrading to each new release as they come out so I'm already on RC10, but since this mostly seems to be an issue of people wanting to see the word "FINAL" somewhere, I say why not.

 

Having said that, I've been speccing out a build on the X9SCM board, so my opinion may change when/if I run into the slow write issue...("Yay. After 8 months I've finally got all 8 drives in my small tower case. My first server is complete. Hmm. I wonder what it would take to expand to 24. Wow you can remote manage a server? and run VMs? And it'll run almost silently? I gotta get in on this!" *sigh* I blame Johnm. ;_;)

Link to comment

My suggestion :

 

Release a final 5.0 now. Make it more stable by ONLY adding bugfixes to it : 5.1, 5.2, 5.3, ... NO new features or new hardware, ONLY bugfixes!!!

 

Make a separate 5.0F version (F from Features) with new features and support for new hardware (that MB with slow write speads would not be supported in 5.0). Those who want, can run 5.xF on their server to test the new features. While working on 5.xF, don't neglect to add bugfixes to 5.x

 

At a certain point in time. 5.x will be quite stable and 5.xF will have several new features/hardware that should have been tested a lot. At that moment, turn 5.xF into 6.0 and start the cycle again. In 6.x the new features introduced in 5.xF will again become more and more stable.

 

People wanting a stable release go for 5.x and can move to 6.x once they feel 6.x is stable enough (starting from 6.4/6.5/...). People who want some new features (or need them due to hardware support) have to go with 5.xF, 6.xF, ...

 

What you just described is basically the "Stable" and "Beta" model just with different names.  But worse, he would still need a beta version for both the bugifxes in Stable as well as while testing the new features in "F" (aka beta .. .so a beta to a beta which is [drum roll] "Alpha")

 

That just sounds like a recipie for pain and confusion.

 

This is not the same as the current stable/beta model. In the current 'stable' (4.x) new features are introduced all the time, example :

 

Changes from 4.7-beta1 to 4.7

-----------------------------

 

No changes (except version string).

 

 

Changes from 4.6 to 4.7-beta1

-----------------------------

 

Feature: Advanced Format drive support - partition 1 may now be aligned on 4K boundry (sector 64)

 

The big difference with the current model is that in the stable release NO new features are introduced, no new hardware is supported, no newer kernel version is introduced, no never version of samba, ...

 

Another difference is also that when working on the features release, bugs are still being fixed in the stable release (the big complaint of most people was that 5 is beta and 4.7 contains some critical bugs).

 

About needing a beta for bugfixes, I don't see why that is needed, not in stable, not in features.

Link to comment

Release 5.0 now and make sure you mention in large bold text that your write speeds may be slower and that this will be address in a future update 5.1 or 5.2.  Please document your speeds in the thread but don't bitch about them since you have been warned.

Such an announcement has to be more explicit. The slow write speeds seem to happen with selected hardware and under specific conditions, do not give the impression that everybody suffers from this...

 

Link to comment

It DOES make a difference...

 

Imagine there you are a first time unRAID user, visit the Limetech main website and need to make a choice in downloading a version... (I bet you most people will choose the "stable" version).

 

Keep in mind that not every user visits this forum, and won't be aware of the status. And evenso many users here can say "it works for me", that is not a true indication that V5 is ready for main stream - according to others.

 

Link to comment

It's not "just a name change". Please stop going down that road. Calling this long awaited version 5 release final has huge implications. It basically publicly states that a new build has finally been deemed stable and bug free enough to be the new recommended and default main build of unraid for all to use. I don't really see the write bug as a huge issue right now until some more people report it. That thread needs more input. A list needs to be made of everyone reporting the issue and their hardware specs, specifically including the amount of ram present and any customizations running. I think if a decision has to be made now, release it. If Tom is happy to wait - and I know this could go on forever - then I think a couple more weeks won't hurt given that this write speed bug seems to be fairly specific and one main area to look at, rather than lots of little bugs.

 

 

Link to comment

Here's my undoubtedly unpopular opinion.  Give Tom more money.

 

I've been using unRaid as a platform for going on 7 years to consolidate my storage needs, and to date I have not incurred any considerable downtime or data loss. During this time, I've gone through numerous server configurations running countless different release candidates, ultimately ending up currently with a build based on the combination of a Norco 4220 & X9SCM-F. It wasn't the most frugal of choices, but came highly recommended on the forums, and has to potential to meet all of my unRaid needs.

 

My biggest disappointment with unRaid has always been its untapped potential. I think I'm not alone here as over the past 7 years as I've seen unRaid adapted to a host of plugins and addons. I check the forums on a regular basis, and yes the lack of communication can be frustrating, but that frustration stems from knowing that no updates means no news.  I love this product and want to see it grow and thrive. I want to see more updates, not less.  If that means incentivizing the developer than so be it. $119 over the past 7 years has been a phenomenal value.

 

Finalize 5. Start development of a 64 bit ASAP, and maybe charge / have a donation drive etc. 

 

 

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.