unRAID Project Roadmap Announcements

[StevenD]

Im quite happy with Private Internet Access as well.

[blockhead]

I'd like to chime in from the somewhat less technical side of things... I'm far from clueless with pc's but I'm no guru, which I *think* makes me Limetech's target demographic. When I started with unraid I think 4.6 was the latest stable release, and at that time, when I bought my licenses, I knew I was buying an unfinished product. I knew there was stuff missing, the core features which I wont list because everybody knows, but it did the one thing I most wanted: It let me throw a bunch of random drives into whatever box I chose and presented those drives back to me as one logical space and with a little fault tolerance. And it did this without requiring me to expand my limited knowledge of Linux. So hell yeah I was willing to bet a hundred bucks or so that unraid would evolve into what I considered a finished product, something less fragile, something I could recommend to my friends. Nobody promised it would happen. It was just a bet.

 

I'm not writing this to complain. I just wanted to say that after reading the "complaint dept" thread and this one, it's clear that in the next few months I will learn whether I won that bet. And also that if this were a movie, Grumpy would be the guy the audience knows the other characters should be listening to. The audience would know any characters who choose to ignore him are all gonna be eaten by frickin sharks or dinosaurs or possibly sharkosaurs. Could happen.

 

And since this is a roadmap thread I'll go ahead and post my dreamlist. In addition to the aforementioned core features, my dream unraid would (I take no credit for these ideas):

 

- automatically move data from a failed disk to a designated warm spare.

 

- automatically move data from a failed disk to any available free space if a warm spare doesn't exist.

 

- allow me to EASILY delete a disk from the array if I have plenty of free space to move the data to, and I don't intend to replace the disk anytime soon. I know some of you cannot possibly imagine reducing the number of drives in your array, but (and yer gonna hafta trust me here) the above situation MAKES PERFECT SENSE to regular humans.

 

And now that those perfectly reasonable requests are out of the way, I'll throw out an unreasonable one: It's funny I was already thinking about this kinda thing when Grumpy posted that stuff about Ceph, but anyway ZOMG I want that!!! How cool it would be to take multiple unraid boxes and have them all replicating and fault tolerating each other over encrypted channels. Yes, fault "tolerating" - I said that. They can do other naughty stuff to each other too I don't care. It would just be so awesome. But I dream.

[jonp]

I'd like to chime in from the somewhat less technical side of things... I'm far from clueless with pc's but I'm no guru, which I *think* makes me Limetech's target demographic. When I started with unraid I think 4.6 was the latest stable release, and at that time, when I bought my licenses, I knew I was buying an unfinished product. I knew there was stuff missing, the core features which I wont list because everybody knows, but it did the one thing I most wanted: It let me throw a bunch of random drives into whatever box I chose and presented those drives back to me as one logical space and with a little fault tolerance. And it did this without requiring me to expand my limited knowledge of Linux. So hell yeah I was willing to bet a hundred bucks or so that unraid would evolve into what I considered a finished product, something less fragile, something I could recommend to my friends. Nobody promised it would happen. It was just a bet.

 

I'm not writing this to complain. I just wanted to say that after reading the "complaint dept" thread and this one, it's clear that in the next few months I will learn whether I won that bet. And also that if this were a movie, Grumpy would be the guy the audience knows the other characters should be listening to. The audience would know any characters who choose to ignore him are all gonna be eaten by frickin sharks or dinosaurs or possibly sharkosaurs. Could happen.

 

And since this is a roadmap thread I'll go ahead and post my dreamlist. In addition to the aforementioned core features, my dream unraid would (I take no credit for these ideas):

 

- automatically move data from a failed disk to a designated warm spare.

 

- automatically move data from a failed disk to any available free space if a warm spare doesn't exist.

 

- allow me to EASILY delete a disk from the array if I have plenty of free space to move the data to, and I don't intend to replace the disk anytime soon. I know some of you cannot possibly imagine reducing the number of drives in your array, but (and yer gonna hafta trust me here) the above situation MAKES PERFECT SENSE to regular humans.

 

And now that those perfectly reasonable requests are out of the way, I'll throw out an unreasonable one: It's funny I was already thinking about this kinda thing when Grumpy posted that stuff about Ceph, but anyway ZOMG I want that!!! How cool it would be to take multiple unraid boxes and have them all replicating and fault tolerating each other over encrypted channels. Yes, fault "tolerating" - I said that. They can do other naughty stuff to each other too I don't care. It would just be so awesome. But I dream.

Awesome feedback and thank you for chiming in with your wishlist.  Hearing feedback from fresh perspectives / different blood is always welcome.

 

Quite simply, the company has significantly invested in itself and its future growth.  More than it ever has before.  This investment started last year with Tom Harms, but this year, it was doubled down upon.  This was not without cost.  In addition, folks can clearly see from our last beta release that there has been a significant uptick in development focus.  This original post was designed to provide even more insights on our development and where we are headed as a company.  I think you're going to win that bet

 

Oh and I'm totally going to start saying "fault tolerating" now

[grumpybutfun]

BTRFS points that interest me

 

Background scrub process for finding and fixing errors on files with redundant copies

 

Checksums on data and metadata (crc32c)

Compression (zlib and LZO)

Batch, or out-of-band deduplication (happens after writes, not during)

 

Additional features in development, or planned, include:

 

Object-level mirroring and striping

Online filesystem check

Hot data tracking and moving to faster devices (currently being pushed as a generic feature available through VFS)

In-band deduplication (happens during writes)

 

I find that these features may be useful for rsync backups, mail archives, source archives, home directories, etc, etc.

 

I know my DVR box uses XFS.  For me I could see mixing usage.

 

Weebo, you know everything I am about to say so this isn't addressed to you, it's for the rest of the unRAID community.

 

For me, BTRFS is the FUTURE for many of the reasons Weebo said above (plus it's like ZFS and going to be a self healing file system on top of the other "cool" things it can do). I suspect in the next year or so it will probably be my file system of choice for my Important Data (a.k.a. unRAID drives).

 

I already use BTRFS on many of my systems for Linux OS, VMs, Docker, etc. I often use / need a lot of the capabilities / features that BTRFS has (and considered "stable" by many). BUT... None of those are CRITICAL DATA that I would care about if I lost. If my Linux OS using BTRFS were to get fried, I simply reload my OS and back up in 10 - 15 minutes. Same thing applies for VMs and Docker.  Now if you ask me, I (and many others) consider BTRFS to be "stable" when it comes to the basic file system features of BTRFS like metadata, recovery tools, error detection, CoW, RAID 0, 1 and 10, etc. but there are many features / functions of BTRFS that I (and many others) do not believe is "stable" like RAID 5 / 6 (which I doubt unRAID would implement / use), deduplication, compression, etc.

 

As it stands today and the foreseeable future, it will not be my file system of choice because I do not trust it with my Important Data yet.

 

Why?

 

You have to better understand and know how the Linux Community works. Once you do, you can than make a more informed decision about which file system for your unRAID drives.

 

When people think Linux... Most think Linus Torvalds who created the Linux Kernel developed all of it. That simple is not true. Yes, Linus created the Linux Kernel and still "oversees" the development of it but he does not "oversee" or develop the 1000s of programs that are needed to have to an OS / Linux Distro. You can't boot into a Linux Kernel and have a working system. You still need all those 1000s of open sourced programs for command line, services manager, be able to format a disk, X (what XBMC / Plex uses to display on your TV / Screen), etc.

 

The Linux Kernel is open sourced and so are all of the 1,000s of programs. Therefore, you have MILLIONS of individuals and Companies (Red Hat, Intel, nVidia, AMD, Tivo, Microsoft, Debian, Arch, Ubuntu, etc.) who contribute code, security fixes, modifications, features, functionality, patches, bug fixes, etc. to either the Linux Kernel or those 1,000+ programs or both.

 

The Linux Kernel is over 5 Million lines of code and has A LOT of very COMPLEX things in it and Linus (and the rest of his team) is not a Master of All or an expert on Video, Network, RAID Device Drivers or File Systems, RAID or NFS. Therefore, you have TONS of Maintainers (usually a team of people and these change from time to time) for all the various components within the Linux Kernel itself.

 

The Maintainers have a place where MILLIONS of people / companies submit new code, modifications, features, functionality, patches, bug fixes, etc. The Maintainers along with a lot of Linux Experts and the various users in the Linux Community test all of these (can be a few days to years) and when those come out of the other end and the Maintainers believe it is stable they submit them to Linus and Company to include in either the new Linux Kernel or Long Term Supported Linux Kernels or both.

 

Millions of People / Companies > New Features / Patches / Bug fixes / etc. > Linux Experts / Users to test > Maintainers once they believe it's stable > Linux Kernel (LTS, New or Both)

 

Let's use Linux Software RAID / mdadm as an example...

 

Neil Brown maintains the Linux Software RAID driver and in his case also the mdadm program (the linux program to administrate / manage RAID). He didn't write the Linux Kernel Module, Ingo Molnar, Miguel de Icaza, Gadi Oxman, H. Peter Anvin did. Those RAID Drivers (RAID 0, 1, 5, 6, 10, etc.) have had 10,000s patches, bug fixes, features, etc. over the years by MILLIONS of people (many by Neil himself). Neil, maintains / responsible for it all and eventually he submits the bug fixes, features, functions, etc. to Linus and Company for inclusion in the Linux Kernel (new, long term supportnor both).

 

If you think about XBMC 13 (Gotham), it was developed for over a year and tested by a lot of us. It eventually had an alpha / beta testing period but even after all of that... After it came out there were several bugs / issues that needed to be fixed once the rest of the world was "pounding away at it". Which is why XBMC 13.1 was released to address those bugs / issues that were uncovered (it came out quickly after XBMC 13.0 too).

 

The EXACT same thing happens with the Linux Kernel and programs like mdadm. Yes, there is A LOT of testing done by A LOT of experts on various hardware, in various scenarios, etc. before it's submitted to the Linus and Company. However, there can / are things that slip through the cracks.

 

Using Neil / Linux RAID / mdadm as an example where a bug can slip through and be a DISASTER...

 

Bug Introduction:

 

These entered the upstream kernel for v3.4-rc1 and v3.4-rc5 respectively, so no main-line released kernel is vulnerable.

 

However the first patch was tagged "Cc: [email protected]" as it fixed a bug, and so it was added to some stable releases.

 

For v3.3.y the bug was introduced by commit ed1b69c5592d1 in v3.3.1 and fixed by commit ff459d1ea87ea7 in v3.3.4, so v3.3.1, v3.3,2, and v3.3.3 are vulnerable.

 

For v3.2.y the bug was introduced by commit 6bd620a44f7fd in v3.2.14 and fixed by commit 31097a1c490c in v3.2.17 so v3.2.14, v3.2.15. v3.2.16 are all vulnerable.

 

The bug was not backported to any other kernel.org kernels. so only those 6 are vulnerable. Some distributors may have picked up the patch applied it to their own kernel so it is possible that other kernels are vulnerable too.

 

e.g SLES11-SP2 introduced the bug in 3.0.26-0.7 and fixed it in 3.0.31-0.9.

 

Ubuntu-precise introduced the bug in Ubuntu-3.2.0-22.35 and fixed the bug in Ubuntu-3.2.0-24.38

 

As you see above, it made it's way through the Neil, to Linus, into the Kernel, past the Linux Distro Maintainers and into SLES and Ubuntu (and all the other Distros that rolled out those Linux Kernels in their Distros too).

 

BUG

 

The effect of the bug is to erase important information from the metadata that is stored on the disk drives. In particular the level, chunksize, number of devices, data_offset and role of each device in the array are erased ... and probably some other information too. This means that if you know those details you can recover your data, but if you don't, it will be harder. (The average Linux user COULD NOT recover from this, trust me.)

 

A lot of us are Alpha / Beta Testers and do not really know it...

 

If you are running Ubuntu, Mint, Arch, Fedora or pretty much any Linux Distro aside from Debian 7 (Wheezy), Slackware, Red Hat, CentOS (100% Clone of Red Hat), etc... you are essentially running a Beta Linux Kernel and 1,000+ Beta Software (that makes up the OS).

 

Debian, Red Hat, CentOS, openSUSE, Slackware, etc. are running Linux Kernels / Software that are months / years old compared to other Linux Distros and they do this on purpose. Those Distros are for Enterprises, File Servers, Web Servers, etc. and they have to be Rock Solid and Companies / Products that use them cannot / do not want to open to the flood gates to all the problems / issues in running a "Beta" Linux Kernel and Programs. For example, Red Hat / Debian / etc. customers never were exposed or at risk to the Linux RAID / mdadm bug I mentioned above. However, Ubuntu and most every other Linux Distro was.

 

Fedora for example is Red Hat's "testing" / "beta" Distro and what they do in Fedora... Those new features / functions / bug fixes / etc that eventually become "stable" to Red Hat... Are rolled out to current, past, future releases of Red Hat.

 

Ubuntu, Mint, etc.... Is this "testing" / "beta" Distros for Debian.

 

unRAID 6 Beta is using what the Linux Community believes to be a Beta Linux Kernel (even though Linux Kernel calls it "stable"). Long Term Kernels (there are 6) are really what the Linux Community and Companies like Red Hat, Debian, CentOS, etc. consider to be stable.

 

Now, don't be alarmed. The latest and greatest Ubuntu even though it is "beta" is not going to delete or thrash your important data if it is sitting on a partition use EXT3, EXT4, Reiser, XFS, etc. Anything done within the Linux Kernel specific to those File Systems are very minor and very well tested before rolling out. Those file systems are not adding / introducing new features or functionality. If there is an update it's either performance, bug / security fix. So if the latest Linux Kernel that Ubuntu uses (although "beta") at worst case will cause a kernel panic (a.k.a Microsofts Blue Screen of Death). With a Kernel Panic or Microsoft Blue Screen of Death... 99% of the time it's not destroying your data (in our case stuff on our unRAID drives because we use Reiser).

 

Back to BTRFS...

 

If you compare BTRFS to the other file systems above... There are TONS of commits from Chris Mason (BTRFS Creator / Maintainer) to every Linux Kernel release and the btrfs-progs (tools to administrate / manage btrfs). You can see where I detail a high level of what the last several Linux Kernel and btrfs-progs here: BTRFS Linux Kernel and btrfs-progs updates overview

 

Now let's take a look at some of those over the last few releases (only a few months):

 

Linux Kernel

 

reworked group accounting, to fix negative numbers after subvol deletion

snapshots are protected during send

pile of send fixes (stability, speed)

snapshot-aware defrag was disabled due to problems

bugfix and stability focused release

 

btrfs-progs

 

fsck: fixes and enhancements to --init-extent-tree mode

fsck: chunk-recover updates

send: check if subvolumes are read-only

restore: fix restoring of compressed files

restore: fix reading of compressed extents

misc bugfixes

 

Now I am by no means a Linux File System expert (I know about as much as you do) BUT if you look at the amounts of and the type of commits that are still taking place regarding BTRFS (not including new features they have in their Road Map and the new bugs those will also have)... I personally do not feel comfortable using BTRFS for my important data.

 

Things like "snapshots are protected during send" and "snapshot-aware defrag was disabled due to problems" and "send: check if subvolumes are read-only and "restore: fix restoring of compressed files" makes me GULP (and I'm a Linux God).

 

For example, can any of you explain what the "snapshot-aware defrag problem" is? When is it going to be fixed? How this affects your BTRFS  snapshots? NO. Before the fix for "restoring of compressed files" do any of think that is / was kind of a big deal?

 

If I was you, I would go take a peak at the following:

 

XFS Bug List - Currently 12 and 95% of those are preformance / clean up related.

 

EXT4 Bug List - Currently 26 and 95% of those are preformance / clean up related.

 

BTRFS Bug List - Currently 140 and most of them would make your butthole pucker if your unRAID Data Drives were using it.

 

Just a few of the BTRFS Bugs: "corrupted file system unable to restore", "filesystem corruption, can no longer mount without -o ro,recovery. No other mount options work.", "btrfs corrupted after hibernating" and "Recent files are not permanently saved on BTRFS filesystems, risk for real system corruption"... None of those give me a warm fuzzy feeling on the inside.

 

Compared to XFS, EXT3, EXT4, Reiser, JFS, ZFS, etc. you do not having anything close to this in either number of commits or bug fixes. Those are only small / well tested bug / security / performance updates.

 

For me, using BTRFS on unRAID cache drive(s) is fine. I need / want some of the things I can do with BTRFS. It's not important data and I can reload Docker, VMs, Apps, etc. if need be.

 

All the reasons above (plus several others) are why there isn't a Linux Server Distro or Linux Distro that uses BTRFS for their default filesystem. Simply put, BTRFS has too many commits, too many new features it will roll out (which are not tested), too many bug fixes, etc at this time. No Linux Distro trusts BTRFS (YET!) and are willing to put their Distros reputation (and your data) on the line.

 

I chose XFS instead of BTRFS for my Hacktastic CentOS unRAID machine. I did this because it has top notch restore / recovering tools, speed for big files, met my current needs. I am not a Linux File System Guru and I never will be. I lean on the experience / expertise / knowledge / wisdom of Linux Servers Distros (who know 1,000,0000 more times than I do about Linux File Systems) when it comes to the File system my important data resides on. So for me, I'm putting my important data that I cannot afford to lose on BTRFS until a Linux Server Distro / those Linux File System Gods tell me it's okay too.

 

Also, when you factor in unRAID on top of BTRFS... I need to know how unRAID plans on handling Linux Kernel (btrfs) / btrfs-progs updates. I would also like to know what / if any changes need to be made to the unRAID Linux Kernel Module. I also want to know how they are going to deal with the BTRFS free space issue (BTRFS does not seem to be able to come up with a solution) and what that means when drives are close to being full / full and split levels (shfs program that deals with all of that). Plus how they plan on configuring BTRFS (you can go crazy with metadata, block sizes, duplication, etc.) and if / what features BTRFS we will be allowed to use.

[johnny121b]

Just an FYI to those that asked/brought this up...  I will be addressing v5 this week as well.  Tom and I felt it would be best to get these announcements out there first, then a Q&A to address all the logical questions that we knew would come up.

 

jonp, I'm concerned you've chosen to ignore several posts in this thread (and even a direct PM) regarding the future of v5, all while replying in several bouts of banter and several discussions regarding v6.

 

[squirrellydw]

V5 is deam IMHO, use 5.0.5 until 6 is released.

[bkastner]

V5 is deam IMHO, use 5.0.5 until 6 is released.

 

We all know this, but should have something official all the same. Any efforts on 5.0.X is a waste of dev time/resources at this point - especially with 6.0 due in less than 90 days, but LT needs to stand up and confirm once and for all.

[johnny121b]

I love Unraid, but I also accept that:

 

This is a one-man effort with high variability.

Promises of delivery date are seldom met.

There WILL be bugs in version 6. 

There will be LOTS of bugs with changes this big.

 

I don't keep my server at the bleeding-edge of code versions, and I don't believe following thru on 5.06 will delay some promised future version significantly.  The majority of the work (for 5.06) must certainly be DONE already.  And I understand a lot of you are seduced by virtualization and are all-too-eager to jump to the latest/greatest.  And that's fine.  Goodness knows I appreciate your complete willingness to throw caution to the wind & risk your data.  That just means I don't have to.

 

My confidence (that there will be significant wrinkles to be worked-out with a change this big) makes my current version all-the-more-important to me, since I will be using it during the loooong process of beta after beta after beta.

[jonp]

Just an FYI to those that asked/brought this up...  I will be addressing v5 this week as well.  Tom and I felt it would be best to get these announcements out there first, then a Q&A to address all the logical questions that we knew would come up.

 

jonp, I'm concerned you've chosen to ignore several posts in this thread (and even a direct PM) regarding the future of v5, all while replying in several bouts of banter and several discussions regarding v6.

I respond to the posts I can when I can.  Its as simple as that.  It is not solely my decision on what to communicate and when, which is why I haven't commented on v5 yet. 

[bkastner]

I love Unraid, but I also accept that:

 

This is a one-man effort with high variability.

Promises of delivery date are seldom met.

There WILL be bugs in version 6. 

There will be LOTS of bugs with changes this big.

 

I don't keep my server at the bleeding-edge of code versions, and I don't believe following thru on 5.06 will delay some promised future version significantly.  The majority of the work (for 5.06) must certainly be DONE already.  And I understand a lot of you are seduced by virtualization and are all-too-eager to jump to the latest/greatest.  And that's fine.  Goodness knows I appreciate your complete willingness to throw caution to the wind & risk your data.  That just means I don't have to.

 

My confidence (that there will be significant wrinkles to be worked-out with a change this big) makes my current version all-the-more-important to me, since I will be using it during the loooong process of beta after beta after beta.

 

What data risk? Other than upgrading binaries which allows 64-bit the core of UnRAID hasn't changed since 5.0. Layering on virtualization doesn't impact data stability. If we were moving from Reiserfs to BTFRS for the core disk partitions, or moving from Slackware to Ubuntu or something else, then sure - significant change that has associated risk. Moving from 5.0 to 6.0 doesn't really introduce this.

 

I also question your assumption that they must be almost done with 5.0.6. This is based on what? Crystal Ball? Secret messages from your Alphagetties? Considering they still haven't released a 6.0 beta with the new features, it would stand to reason they haven't really looked into back-porting it to the 5.0 stream.

 

Feel free to sit quietly in the corner, jumping at every noise hoping the boogieman won't find you, but sorry, moving to 6.0 is not a life changing event, where we are all trying to car-surf on the freeway. UnRAID's core parity based solution is well proven and tried, and there is no real risk to your data by moving to it.

 

As for your prediction of "LOTS of bugs"... I wouldn't put to much stock in this either - some new functionality like virtualization/Docker are going to require refinement, and it's possible the UPS/Email Notification piece may require a few releases to be rock solid, but you can still run all your usual 5.0 plugins thanks to PhAzE's efforts, so again no real risk, and while there may be some bugs/issues, again, no-one is reinventing the world here. It's not like Tom and team have decided to start coding in Chinese just for the extra thrill.

 

Talk about FUD.

[pyrater]

Just an FYI to those that asked/brought this up...  I will be addressing v5 this week as well.  Tom and I felt it would be best to get these announcements out there first, then a Q&A to address all the logical questions that we knew would come up.

 

jonp, I'm concerned you've chosen to ignore several posts in this thread (and even a direct PM) regarding the future of v5, all while replying in several bouts of banter and several discussions regarding v6.

I respond to the posts I can when I can.  Its as simple as that.  It is not solely my decision on what to communicate and when, which is why I haven't commented on v5 yet.

 

 

Anyone have some burn cream?

[johnny121b]

What data risk? Other than upgrading binaries which allows 64-bit the core of UnRAID hasn't changed since 5.0.

We've been at version 5 through the last 30 releases (15 betas and 16 release candidates), and we're only at v5.05....

 

I applaud your optimism that the leap to version 6 must be such a minor thing.  Pity you can't apply that same optimism to 5.05 -> 5.06

 

I also question your assumption that they must be almost done with 5.0.6. This is based on what? Crystal Ball? Secret messages from your Alphagetties?

Perhaps it's the headline stating the latest release is v6.0beta6; meaning there have been 5 other releases with zero mention of any sort of discontinuation of version 5.  Perhaps it was the mention last week that word was coming on version 5.  Call me silly for daring to presume a final version of 5 was in-the-works. 

 

As for your prediction of "LOTS of bugs"... I wouldn't put to much stock in this either

You've made your opinion of my judgement very clear. 

[bkastner]

What data risk? Other than upgrading binaries which allows 64-bit the core of UnRAID hasn't changed since 5.0.

We've been at version 5 through the last 30 releases (15 betas and 16 release candidates), and we're only at v5.05....

 

I applaud your optimism that the leap to version 6 must be such a minor thing.  Pity you can't apply that same optimism to 5.05 -> 5.06

 

To be fair though, those 30 releases were spanned over a 4 year period where there didn't appear to be any clear vision of what 5.0 would look like, nor as much focus from Tom as customers would have liked. Many of the builds were due to ever evolving technology over the 4 year dev period with minor bug fixes. 6.0 doesn't suffer from the same limitations in that there are now multiple devs working on the product, they have a clear goal for 6.0 and a targeted release window.

 

As far as optimism goes, I don't need it. In place of optimism I prefer to rely on common sense. I think 5.0.6 is a WASTE OF TIME, as I have commented on several times in this and other threads. I am optimistic that LT realizes that by pushing out 5.0.6 they are only trying to placate a small subset of users who are bitching for basically nothing, and after 5.0.6 comes out they will find another reason to start. Why bother? Far better to invest 100% of dev time into getting 6.0 out the door with all the features 5.0 tried to complete. Then those who want can continue to use plugins like in 5.0 and for others they can use Docker/VMs.

 

I also question your assumption that they must be almost done with 5.0.6. This is based on what? Crystal Ball? Secret messages from your Alphagetties?

Perhaps it's the headline stating the latest release is v6.0beta6; meaning there have been 5 other releases with zero mention of any sort of discontinuation of version 5.  Perhaps it was the mention last week that word was coming on version 5.  Call me silly for daring to presume a final version of 5 was in-the-works. 

 

Why would a 6.0 beta cycle talk about the discontinuation of 5.0? When has Microsoft, when releasing customer previews or tech betas for a new OS included comments "Oh by the way, we are not working on the old OS anymore"? Actually, when has any OS manufacturer done that.

 

I agree LT needs to burst your guys bubble and confirm that 5.0 is dead, but I serious doubt that will be the end of it. It will just generate a new topic of bitching on "How could LT have done this to us". I am guessing a lot of you 5.0 diehards are also first to jump on board for petitions to save old TV shows. Get over it... it's gone.

 

As for your prediction of "LOTS of bugs"... I wouldn't put to much stock in this either

You've made your opinion of my judgement very clear.

 

*Whew* I was afraid I might have been to subtle.

 

[blockhead]

I am optimistic that LT realizes that by pushing out 5.0.6 they are only trying to placate a small subset of users who are bitching for basically nothing, and after 5.0.6 comes out they will find another reason to start.

...

I am guessing a lot of you 5.0 diehards are also first to jump on board for petitions to save old TV shows. Get over it... it's gone.

 

Oh man that is low. Haven't you ever lost a show? Did you watch Firefly?@! Some shows deserve a good finale. That's what we in the "small subset" would like. And as for the size of our subset, please don't be insulting. Yours *might* be bigger, but that's no reason to point and laugh.

 

I've been told our subset is "a good size," and "more than adequate." I don't understand why you would underestimate / minimize / denigrate it. I believe this is how the forum works: Most people only post when they can't find the solution to their particular issue, or if in threads like these they don't see their viewpoint being expressed. The rest of the time it's just reading for most of us. Imagine this thread if all 60k members wanted to throw in 2 cents! Maybe if the forum had Like / Dislike buttons on our posts we'd get a better idea of just how much support there is for various viewpoints.

 

In the meantime, c'mon man, give us a little respect. Many of us want a better v5 while we wait for at least an RC of the 6.0 variety. Call us mad, kooky, irrational, nonsensical, superstitious, nutty, wacky, bone-headed, reasonless, brainless, cockamamie, demented, or (yes I went to the thesaurus for this) injudicious, but we don't like running betas. And the current release version needs stuff.

 

If they could just do one last upgrade with that stuff, maybe call it 5.1, keep the bug fixes going until at least the first 6.0 RC, then I think we'd be done with 5, and then we could concentrate on fighting over the direction of 6.

[PeterB]

Many of us want a better v5 while we wait for at least an RC of the 6.0 variety.

 

The problem with your scenario is that the current development source tree appears to be v6.0.  The likelyhood is that v6.0 will be released with the enhancements you are looking for, before backporting those enhancements into the v5 source.  We have already been told that v6.0 final is going to be released by the end of September.  To divert the development resource onto v5, remembering that two of the three developers have not worked on v5, is likely to cause delays and increase costs.

 

My suspicion is that after v6.0 is released in September,we are going to see another poll on the forum to ascertain how many users really are sticking with v5.x, and for what reason.  The only valid reason I can see is the lack of 64-bit hardware support.  On the other hand, if the reason is in order to retain a favourite plugin, then resource might be better applied to porting that plugin to v6, or creating a docker container for it.

[blockhead]

We have already been told that v6.0 final is going to be released by the end of September.

 

That's true. September is not that far away and I can wait. It does seem a wee bit optimistic though, given that it's July and we don't yet have a beta with the slew of new features that have been announced. Oh well. What happens happens.

[bkastner]

I am optimistic that LT realizes that by pushing out 5.0.6 they are only trying to placate a small subset of users who are bitching for basically nothing, and after 5.0.6 comes out they will find another reason to start.

...

I am guessing a lot of you 5.0 diehards are also first to jump on board for petitions to save old TV shows. Get over it... it's gone.

 

Oh man that is low. Haven't you ever lost a show? Did you watch Firefly?@! Some shows deserve a good finale. That's what we in the "small subset" would like. And as for the size of our subset, please don't be insulting. Yours *might* be bigger, but that's no reason to point and laugh.

 

Okay, I am willing to concede it would have been great if Firefly went longer, though at least they got Serenity to help provide a last story.

 

Trust me, there are a number of shows I would watch if they came back, but I know better than to hold my breath!

[bkastner]

We have already been told that v6.0 final is going to be released by the end of September.

 

That's true. September is not that far away and I can wait. It does seem a wee bit optimistic though, given that it's July and we don't yet have a beta with the slew of new features that have been announced. Oh well. What happens happens.

 

I agree it feels somewhat optimistic, but this month will really tell us how likely it is. As long as we get a 1-2 final betas this month, or a little into Aug and LT can then switch to RCs I think it can be done, but only time will tell. I prefer to reserve what optimism I have for this scenario.

[tgggd86]

JONP/LT,

 

Really appreciate the straighforward update.  I think this is an excellent direction for unRAID and includes features that have been long requested.  I was looking forward to playing around with VMs once the kinks had been worked out, but I think I can hold out a bit longer.

 

I think it's important for people to realize that with how long it took to make v5 final, this is a great sign that LT is focused on making a stable release available sooner, rather than spending tons of time focusing on niche features.  This is the direction unRAID NEEDS to go and will help LT break away from the lack of support it provided to users in the past.  I for one would probably be listed in the top 10 of people being burned by lack of end user support, but with Joe hiring more devs and the increased discussion that LT has had with it's users on this forum I am hopeful for the future.

 

I'm one of the people that was hoping for 5.0.6 to fix the web GUI, but with this announcement, I'm okay with waiting until V6 is realeased.  Hopefully we don't run into the busted suspenses of past, where it takes two whole years past the promised date of release.

[WeeboTech]

I'm pretty optimistic that with the driving force behind unRAID/Limetech lately, we'll see a release.

 

We may not see every single feature implemented, but we should see a working usable release.

 

 

[Brucey7]

IMHO there is far too much "noise" in the direction unRAID is going.

 

It's a fileserver system for storing data and that is all it should do to the best of it's ability, in the simplest, safest way at the minimum cost.  I have zero interest in virtualization, docker, unMENU, Sickbeard or indeed any add-on's whatsoever and I view all development in this direction as bad news (increasing risk).  I keep my add-on's where they should be on a completely separate system.

 

We are getting perilously close to the volume limit for a disk in the ReiserFS, disks will probably exceed it within 5 years.  1 parity disk is not enough.  64 bit support is useful. more than 30 disks supported is useful.  Everything else is noise and limits the attraction of unRAID to anyone doing a serious study into what they choose to buy to store their increasing collection of home data on, and lets be honest, that is the current & future market for unRAID, it's not the hardcore band of hobbyist/enthusiast who wants it to make them a coffee of tea first thing in the morning whilst singing yankee doodle dandy.

 

I currently have multiple RAID6 servers, an unRAID server filled to capacity with 22 drives and another system on order from Greenleaf.  I am a retired Global IT Director of a fortune 500 company and I keep my servers where they should be, out of sight.  If one of my staff tried to run applications on a mission critical SAN he would have been fired on the spot.  I rely on my fileservers to serve data... on demand with a minimum TCO and maximum reliability, as the saying goes "KISS".

 

I would far prefer to run on one big, safe, economical, reliable, expandable server and for what it's worth, that's the only development I would like to see from Limetech.

[bkastner]

IMHO there is far too much "noise" in the direction unRAID is going.

 

It's a fileserver system for storing data and that is all it should do to the best of it's ability, in the simplest, safest way at the minimum cost.  I have zero interest in virtualization, docker, unMENU, Sickbeard or indeed any add-on's whatsoever and I view all development in this direction as bad news (increasing risk).  I keep my add-on's where they should be on a completely separate system.

 

We are getting perilously close to the volume limit for a disk in the ReiserFS, disks will probably exceed it within 5 years.  1 parity disk is not enough.  64 bit support is useful. more than 30 disks supported is useful.  Everything else is noise and limits the attraction of unRAID to anyone doing a serious study into what they choose to buy to store their increasing collection of home data on, and lets be honest, that is the current & future market for unRAID, it's not the hardcore band of hobbyist/enthusiast who wants it to make them a coffee of tea first thing in the morning whilst singing yankee doodle dandy.

 

I currently have multiple RAID6 servers, an unRAID server filled to capacity with 22 drives and another system on order from Greenleaf.  I am a retired Global IT Director of a fortune 500 company and I keep my servers where they should be, out of sight.  If one of my staff tried to run applications on a mission critical SAN he would have been fired on the spot.  I rely on my fileservers to serve data... on demand with a minimum TCO and maximum reliability, as the saying goes "KISS".

 

I would far prefer to run on one big, safe, economical, reliable, expandable server and for what it's worth, that's the only development I would like to see from Limetech.

 

Sorry to break it to you, but you are in the severe minority in this opinion - both for current users, and for the vast majority of future users. 1 Server for 1 Task went out of fashion 5-7 years ago (or longer). Most people want to be able to do more and more with existing servers, not less and less.

 

Virtualization is the future and is pervasive in just about any enterprise today as it allows people to better utilize their hardware investment, and for a home/SOHO market the direction LT is taking makes perfect sense.

 

You are entitled to your opinion, and you have a valid use case, but for the vast majority of current and prospective UnRAID clients this is not the standard mentality.

[squirrellydw]

 

Sorry to break it to you, but you are in the severe minority in this opinion - both for current users, and for the vast majority of future users. 1 Server for 1 Task went out of fashion 5-7 years ago (or longer). Most people want to be able to do more and more with existing servers, not less and less.

 

Virtualization is the future and is pervasive in just about any enterprise today as it allows people to better utilize their hardware investment, and for a home/SOHO market the direction LT is taking makes perfect sense.

 

You are entitled to your opinion, and you have a valid use case, but for the vast majority of current and prospective UnRAID clients this is not the standard mentality. 

In your opinion

[bkastner]

 

Sorry to break it to you, but you are in the severe minority in this opinion - both for current users, and for the vast majority of future users. 1 Server for 1 Task went out of fashion 5-7 years ago (or longer). Most people want to be able to do more and more with existing servers, not less and less.

 

Virtualization is the future and is pervasive in just about any enterprise today as it allows people to better utilize their hardware investment, and for a home/SOHO market the direction LT is taking makes perfect sense.

 

You are entitled to your opinion, and you have a valid use case, but for the vast majority of current and prospective UnRAID clients this is not the standard mentality. 

In your opinion

 

Yes, it's my opinion, just as the original poster has his. However, reading the forums on a daily basis there are a large number of people who are looking at installing various add-ons, which supports my position. I realize not everyone does, which is of course fine, but there are a lot of people who don't just want static data - they also want an automated method of getting new data and have it rolled into their data repository. Plus a whole bunch of other things people are trying to do.

 

There will always be those who only want to store data, and there is nothing wrong with that, however for those users there is also a lot less compelling reason to upgrade UnRAID. The benefits are really for those who want to get more out of their systems (which I still think is the majority of users).

 

[bubbaQ]

Sorry to break it to you, but you are in the severe minority in this opinion

 

I have to agree.  I come from a very similar background as Brucey7, and would have fired the same people for the same things he describes.  I use unRAID very differently than I did any server in the corporate environment. The home market, and home entertainment/media storage and serving that media up to an array of devices is a very different ballgame then file services in a corporate environment.  It's a lot more like a small company environment where getting any $$$ for capital expenditures is asking for rain in the Sahara.  Make do with less and stack multiple functions on each box.  The maturity of visualization severely enhances the security of that stacking, so the guy running an buggy nightly build of an SQL engine on that SAN can't crash it like he could in the old days.