Release Plan for 5.0

First I want to thank everyone for their vote and/or comment in the Your Chance to Chime In Poll.  There were quite a few opinions I hadn't considered before.

As you have probably seen, I went ahead and released another "rc" -rc11.  Hopefully this will be the last -rc.  One of the changes is the inclusion of a boot menu item that will let you boot the linux kernel limiting it's memory to 4GB.  This is a "workaround" for the "slow-write" problem seen on certain systems.

While the results of the poll indicate that we should just release 5.0 as-is and address this issue in 5.1, I really don't want to do that because there is only going to be one chance for me to produce a "final" that everyone from 4.7 can move to, and I'd like it to not have this (fairly major) workaround.

At least I need to understand the cause of this problem.  To this end, we have set up a test system where I can figure out what's going on.  The plan is to give this a week.  Hopefully I can solve this problem and release a fully-functional 5.0 with any amount of RAM.

Moving forward, work has already started on a fully 64-bit unRaid OS.  Highlights:

a) Based on slackware64-14.0

b) latest netatalk (3.x)

c) latest samba (4.x)

d) integration of lighttpd+php with emhttp

In addition, there is a very cool feature that will probably be released prior to a 64-bit kernel called "cache pool".  This feature allows you to assign multiple hard drives to the "cache" using the btrfs file system.  Among other things, this will provide fault tolerance for cache-only shares and for files not yet moved to the array.  This will also provide a great way to utilize SSD's in an unRaid server since btrfs has SSD-aware features.

fantastic! and WOW I love unRaid again now we are getting all the info!

Thanks for the hard work! You had mentioned multiple arrays to support your new server product. So..

1) is this coming in the 64-bit version?

2) is that server going to be available soon? I want to get 1 or 2 for my family.

Cheers!

whiteatom

At least I need to understand the cause of this problem.

I think that it is this 'understanding' which is important - at least it should then be possible to predict which systems are going to be affected.  I would still be surprised if the problem is isolated to X9 series motherboards, or even C20x chipsets.

A 'workaround' solution would still be acceptable if a 'proper' fix can only be achieved with 64 bits, or a protracted wait for a fix to be backported to our current kernel.  I say this even though my X9SCM-iiF hardware will be delivered later today.

Thank you for your hard work Tom.

Thanks Tom.

thanks tom - i purchased x2 Pro Keys a year ago - waiting on the promise of 5.0. Glad to finally put them to good use!

Can't wait for the 64-bit kernel release!

I am also really looking forward to cache pooling. I've got like 15 320GB laptop drives laying around. It will be awesome to put a few of them in a btrfs pool and worry less about the cache failing and loosing all my plugin data.

Tom, I'll be in So-Cal for two weeks in the beginning of February.

I could drop off an X9SCM, Xeon/I3 and 16 gigs of ram for you to play with while I'm in town... If you think this would help out with this issue..

you could  also ship it back if you need a test rig for a bit for the 64bit testing also.

That's great news Tom, thanks for keeping the board informed of your progress.

Looking forward to the 64bit release.

Will a 64-bit release still work on older (32-bit) hardware?

Will a 64-bit release still work on older (32-bit) hardware?

I do not think that is technically possible!

Thanks for the update Tom. I'm excited to see a fully-reliable 5.0 final.

As my grandpa said (and still says):

If it's worth doing, it's worth doing right.

I think you made the right decision to hold off release until you feel comfortable about it. After all, you only get one chance at a first (5.0) impression!

Will a 64-bit release still work on older (32-bit) hardware?

No but many people kit will be 64bit and they wont even know it.

Tom perhaps we can head this off at the pass and have a flag somewhere in the emHTTP that tells people if their CPU is 64bit capable.

Otherwise were going to see this question re-occur hundreds of times

Will a 64-bit release still work on older (32-bit) hardware?

 

No but many people kit will be 64bit and they wont even know it.

 

Tom perhaps we can head this off at the pass and have a flag somewhere in the emHTTP that tells people if their CPU is 64bit capable.

 

Otherwise were going to see this question re-occur hundreds of times

Great idea!  Specifically inform a user that their system is not 64bit capable.  Someone should also start a poll, who still REQUIRES 32bit only, and who is ready for 64bit or will be when a 64bit version is ready.

Will a 64-bit release still work on older (32-bit) hardware?

 

No but many people kit will be 64bit and they wont even know it.

 

Tom perhaps we can head this off at the pass and have a flag somewhere in the emHTTP that tells people if their CPU is 64bit capable.

 

Otherwise were going to see this question re-occur hundreds of times

 

Great idea!  Specifically inform a user that their system is not 64bit capable.  Someone should also start a poll, who still REQUIRES 32bit only, and who is ready for 64bit or will be when a 64bit version is ready.

There will be a lot of us with older (but perfectly functional) servers who will be stuck on a 32 bit OS.

I'm 99.9% certain my original unRAID server with the Intel D865GLCLK MB and Celeron CPU is 32 bit only.

 

There will be a lot of us with older (but perfectly functional) servers who will be stuck on a 32 bit OS.

If it's Willamette core it's 64bit, if it's Nortwood it's 32 bit only

I'm 99.9% certain my original unRAID server with the Intel D865GLCLK MB and Celeron CPU is 32 bit only.

 

There will be a lot of us with older (but perfectly functional) servers who will be stuck on a 32 bit OS.

 

If it's Willamette core it's 64bit, if it's Nortwood it's 32 bit only

Windows Server 2013 is now 64bit only... some times you just need to move on.

I'm 99.9% certain my original unRAID server with the Intel D865GLCLK MB and Celeron CPU is 32 bit only.

 

There will be a lot of us with older (but perfectly functional) servers who will be stuck on a 32 bit OS.

 

If it's Willamette core it's 64bit, if it's Nortwood it's 32 bit only

Willamette core CPUs were the initial NetBurst cores. Northwood came after it.

Windows Server 2013 is now 64bit only... some times you just need to move on.

Even Windows 2008R2 was 64bit only

That all sounds amazing, especially the idea of a more tolerant cache.  BUT, this is down right scary:

Btrfs (B-tree file system, variously pronounced "Butter F S", "Butterfuss", "Better F S",[4] or "B-tree F S"[5]) is a GPL-licensed experimental copy-on-write file system for Linux. Development began at Oracle Corporation in 2007. It is still in heavy development and marked as unstable. Especially when the filesystem becomes full, no-space conditions arise which might make it challenging to delete files.[6][7]

Emphasis is mine.  Of course if the main culprit is over filling the system, then it might be wise to institute max capacity level for any Btrfs drives.  Not the same as the current "min space" control we have now I think, but maybe that will suffice.  But it would need to be made very clear how important it is for this to be set correctly.

That all sounds amazing, especially the idea of a more tolerant cache.  BUT, this is down right scary:

 

Btrfs (B-tree file system, variously pronounced "Butter F S", "Butterfuss", "Better F S",[4] or "B-tree F S"[5]) is a GPL-licensed experimental copy-on-write file system for Linux. Development began at Oracle Corporation in 2007. It is still in heavy development and marked as unstable. Especially when the filesystem becomes full, no-space conditions arise which might make it challenging to delete files.[6][7]

 

Emphasis is mine.  Of course if the main culprit is over filling the system, then it might be wise to institute max capacity level for any Btrfs drives.  Not the same as the current "min space" control we have now I think, but maybe that will suffice.  But it would need to be made very clear how important it is for this to be set correctly.

Meh, if you knew how many things were marked "experimental" in the kernel you'd be amazed.  There's also this:

SUSE Linux Says Btrfs is Ready to Rock

Windows Server 2013 is now 64bit only... some times you just need to move on.

Where you may see obsolescence, others see stability.  One of UnRAID's main selling points, is that it ISN'T a hardware-hog.  In any case, I don't base my upgrade desires on Microsoft's example.  We're serving files here, not rendering 4Gb CAD files, and in many cases, we're serving files from nice, slow GREEN drives.  I'd much rather have a server that takes two extra seconds to begin serving my HD movie and WOULDN'T catch fire if every fan seized up.