Apology and Plan Moving Forward

[limetech]

1: So you plan to use the later Kernel for getting 5 to final, and fixing the crashing when stopping the array? Can you state why you feel this a better option than sticking with the current earlier kernel used in RC14 other than it just being newer? RC14 seems to have NO reported issues whatsoever - I am not counting 4gb issues.

Sorry I didn't intend to imply that 5.0 will be released with the 3.9 kernel; it will be released with the 3.4 kernel.  I was just saying that the 'slow write' issue will probably never be fixed in the 3.4 series, but the sync/stop issue will certainly get fixed in 3.9 series, or perhaps 3.10.  I've been corresponding with the reiserfs maintainer at SUSE and he will not be able to look at this problem until next Monday at earliest.

 

Also it's worth noting that no new features and relatively few bug fixes are put into the Long Term supported kernels.  For example, already the 3.9 kernel uses better mpt2sas driver than what's in 3.4 and they would never backport the new driver to 3.4.  So there are certainly valid reasons to keep up with kernel releases.

 

2: Will licences bought for 32bit version be transferable to 64bit version?

Current plan is Yes.

 

3: Will the upgrade from 32bit to 64bit just be "another simple upgrade" for us users in that we can update our USB drive and then boot back up and expect the array to behave as before, or will there be more to it?

For 'stock' unRaid, yes.  For plugins there might be some grief depending on what packages get loaded.  Probably we will include the multilib package that should let 32-bit apps run on the 64-bit platform, but there will probably be some issues too.

 

4: What approximate ETA would you set yourself for having 5 final right now?

Last week?  Well just as soon as possible.  I have to finish the documentation and get some more feedback on the open issues first.

 

5: What approximate ETA would you set yourself for having 6 released into the wild for testing?

To add some more detail, there probably will not be a "6.0", probably will start at "6.1", this is because:

5.1 - will be refresh of the slackware platform to slackware-14.0, hence,

6.1 - will be based on slackware64-14.0

 

There were other features I wanted to put into 5.1 before changing slack platforms (such as "cache pool", integration of lighty and coding up the plugin manager), but in light of the "severe" workaround to fix 'slow write' I am giving 64-bit kernel higher priority.  What could change this would be a patch in the near future that solves the "sync/stop" problem, in which case I would have to re-evaluate and maybe release a 5.1 that moves to (fixed) 3.9 kernel.

 

[Ironcross]

Thanks for the update Tom.  Much appreciated.

[madburg]

Sweet update, thanks!

[drawz]

Thanks for the updates and roadmap! Very much appreciated.

 

The delay is no big deal since we know what's going on.

[Cessquill]

Oh also I wanted to say, anyone that runs hardware not capable of running a 64bit kernel...good riddance. No offense, but the world can't wait around catering for such old tech.

To be fair, I run unRAID completely stock.  I was sold on the basis that it's a relatively affordable way to get a large, mainly read-only, NAS drive solution with a failure mechanism built in.  I put together a a fairly meager system (motherboard with 8x SATA ports and onboard Gig LAN port, low power processor, 2Gb RAM, PSU), and I've been filling it with WD Green Power drives since.  The only changes I've made are to update to a more beefy power supply and add a Supermicro 8 port SATA card.

 

The system works virtually flawlessly; it's not the fastest out there, but things like parity check speeds aren't really a concern if I'm running overnight.  I have no idea whether it'll run 64-bit though.  It might, I guess.  I've been keeping up with releases to take advantage of any driver updates and speed improvements (and the fact that I might run >2TB drives in the future).  The FTP option has come in quite handy recently too, but it ultimately still does what I need it to, and its requirement hasn't changed.  I don't really need add-ins, since I have a Windows Home Server running that handles all network apps.

 

Would I rip out my mobo, RAM and CPU if I needed to in order to get a 64-bit file server?  Don't know really, but my hand might be forced if - say - new drives were released that only the 64-bit version supported.

[Joe L.]

Would I rip out my mobo, RAM and CPU if I needed to in order to get a 64-bit file server?  Don't know really, but my hand might be forced if - say - new drives were released that only the 64-bit version supported.

Odds are very high your MB/CPU would be fine, but you can be sure if you type this command via telnet or n the system console:

 

At a console or in a Telnet session type:  (quote from NAS)

cat /proc/cpuinfo | grep -Gq "flags.* lm " && echo '64bit' || echo '32bit'

 

If it is 64bit capable, it will say so.

[jumperalex]

Tom, for what its worth I hope you realize just how important these updates, and the recent presence you've had in the other threads, are.  I can't and won't judge your life's priorities so if other things conspired to limit your updates in the past, no harm no foul.  But I hope the responses in this thread and the recent RC threads have shown just how much GOOD WILL you gain from keeping us informed.  Frankly, we'd probably take any amount of delays at this point if we knew to expect it. 

 

So for all that let me say Thank You!

 

Obviously though you've also found the one dark side to being so engaged: you felt badgered and rushed into pushing something out before having the time to really think it through and test it.  I've been there myself many times.  Mind you, just as important is that your quickly recognized the error and made moves to correct it.  The next lesson is to learn when to say, "ok guys, give me a day to think about this", disengage, step back, and work without distraction.  At a minimum a good night's sleep is critical to put things into perspective.

 

[EDIT]: In fact when feeling the "rush" is the best time for Tom#2 to step in and act as your filter so the world slows down for you to work.

[/EDIT]

 

Sooo once again thanks for a great product, thanks for finally being more engaged, and most of all, thanks for keeping us informed (which is indeed distinct from being engaged).

 

Cheers.

[Interstellar]

Sounds good to me.

[gvers]

Just like to say thanks for the update. Looking forward to 5 finals.

[Cessquill]

Thank you Joe L for the 64 bit test line, I'll run it shortly.  Well, thank you again since you've helped me out a couple of times.

 

And to echo other sentiments on this thread, thank you Tom.  From some of the interactions I read on here, it sometimes seems like the tail is trying to wag the dog.  Don't be pushed into implementing something you haven't considered.  And have a good weekend.

[Cessquill]

At a console or in a Telnet session type:  (quote from NAS)

cat /proc/cpuinfo | grep -Gq "flags.* lm " && echo '64bit' || echo '32bit'

 

If it is 64bit capable, it will say so.

Thanks - I'm 64-bit capable according to this.  Might be a useful command for those of us that aren't quite as savvy.

[JonathanM]

Would I rip out my mobo, RAM and CPU if I needed to in order to get a 64-bit file server?  Don't know really, but my hand might be forced if - say - new drives were released that only the 64-bit version supported.

Odds are very high your MB/CPU would be fine, but you can be sure if you type this command via telnet or n the system console:

 

At a console or in a Telnet session type:  (quote from NAS)

cat /proc/cpuinfo | grep -Gq "flags.* lm " && echo '64bit' || echo '32bit'

 

If it is 64bit capable, it will say so.

Joe, perhaps you should add that as a separate button in the system info section of unmenu. At least that way people with command line allergies have a quick place to look.

[Joe L.]

Would I rip out my mobo, RAM and CPU if I needed to in order to get a 64-bit file server?  Don't know really, but my hand might be forced if - say - new drives were released that only the 64-bit version supported.

Odds are very high your MB/CPU would be fine, but you can be sure if you type this command via telnet or n the system console:

 

At a console or in a Telnet session type:  (quote from NAS)

cat /proc/cpuinfo | grep -Gq "flags.* lm " && echo '64bit' || echo '32bit'

 

If it is 64bit capable, it will say so.

Joe, perhaps you should add that as a separate button in the system info section of unmenu. At least that way people with command line allergies have a quick place to look.

It is already on the "CPU Info" button in the System-Info section of unMENU.  (Have you checked for unMENU updates in the past 5 minutes or so.  The updated version has been there for at least that long.  )

 

Joe L.

[limetech]

Oh also I wanted to say, anyone that runs hardware not capable of running a 64bit kernel...good riddance. No offense, but the world can't wait around catering for such old tech.

To be fair, I run unRAID completely stock.  I was sold on the basis that it's a relatively affordable way to get a large, mainly read-only, NAS drive solution with a failure mechanism built in.  I put together a a fairly meager system (motherboard with 8x SATA ports and onboard Gig LAN port, low power processor, 2Gb RAM, PSU), and I've been filling it with WD Green Power drives since.  The only changes I've made are to update to a more beefy power supply and add a Supermicro 8 port SATA card.

 

The system works virtually flawlessly; it's not the fastest out there, but things like parity check speeds aren't really a concern if I'm running overnight.  I have no idea whether it'll run 64-bit though.  It might, I guess.  I've been keeping up with releases to take advantage of any driver updates and speed improvements (and the fact that I might run >2TB drives in the future).  The FTP option has come in quite handy recently too, but it ultimately still does what I need it to, and its requirement hasn't changed.  I don't really need add-ins, since I have a Windows Home Server running that handles all network apps.

 

Would I rip out my mobo, RAM and CPU if I needed to in order to get a 64-bit file server?  Don't know really, but my hand might be forced if - say - new drives were released that only the 64-bit version supported.

I would never completely eliminate 32-bit version.  It might go "end-of-life" with a frozen feature set, but this is just a "might" and would never happen without thorough review by the Community.

[limetech]

...

So for all that let me say Thank You!

...

I very much appreciate your post, thank you.

[limetech]

There is an UPDATE! - please refer to the bottom of the first post in the thread.

[calypsocowboy]

Thanks for all your hard work and awesome news!

[JackBauer]

There is an UPDATE! - please refer to the bottom of the first post in the thread.

 

When do you think you'll post rc15?

[WeeboTech]

Out of curiosity.. what is the benefit of going 64bit, aside from PAE

Just being able to remove PAE and still access memory above the 3.5GB line is reward enough for some. To be honest, considering just the basic functionality of a NAS with no addons, there really isn't any benefit I can think of to running huge amounts of RAM. However, most of the active forum members run addons, many run LOTS of addons, and some even run virtual machines inside of unraid. I personally have 3 virtual machines running all the time, with a couple more running sporadically. If I couldn't use more than 3.5GB of RAM, I'd have to use physical machines for those functions. My lowest steady RAM usage is currently over 4GB.

 

 

For some (me) the kernel is tuned to use the buffer cache more. I've done this since early 4.x versions.

Early on I recompiled the kernel and enabled PAE before it was standard.

 

The extra ram and tunings has the added benefit caching data read and providing faster write "burst" access.

Since I maintain .FLACS, MP3's along with using bittorrent over the network, this improves response to the applications.

 

Normally it would not matter, however if you are tagging a bunch of files, adding artwork or doing massive renames, it helps.  Having huge amounts of ram and buffer cache makes up for unraid's slower writes.

 

With my tests I can burst up to 90MB/s to around 1GB, then it slows down.

By the time I hit 4GB it's around 35MB/s which is expected and the norm for all of the systems I've configured.

 

This is why I say "burst". In my case it's good. a CD will rip to about 500GB as a .flac.

I can then turn around and remake a set of mp3's from the flacs without seeing a significant network slowdown.

I can then retag the files, import artwork, etc, etc without having to do it locally on my SSD.

 

So there is an added benefit from large amounts of ram. For some it's not worth the cost.

For me, I'm accessing my unRAID server constantly. It's my fileserver.

All my music and My Documents folders are on the unRAID server.

[jumperalex]

There is an UPDATE! - please refer to the bottom of the first post in the thread.

 

Wow that is awesome.  Is there a short version explanation of what the patch patches?  Just for those of us who are curious.  Of course don't spend more than 5 mins writing it, pushing rc15 is way more important.

[BobPhoenix]

UPDATE: yesterday (13 June) Jeff Mahoney of SUSE Labs, who is the current maintainer of reiserfs, sent me a patch that fixes the "continuous writes" caused by 'sync' command, and also fixes the "crash when Stopping array" bug as well.  This changes the landscape quite a bit and I'd like to release -rc15 with patched 3.9.6 kernel.

Sounds like a great idea to me!

[Harpz]

UPDATE: yesterday (13 June) Jeff Mahoney of SUSE Labs, who is the current maintainer of reiserfs, sent me a patch that fixes the "continuous writes" caused by 'sync' command, and also fixes the "crash when Stopping array" bug as well.  This changes the landscape quite a bit and I'd like to release -rc15 with patched 3.9.6 kernel.

 

Great news, I look forward to testing the new version out when its released

[mr-hexen]

thumbs up for Jeff for the quick resolution for sure!!

[madburg]

UPDATE: yesterday (13 June) Jeff Mahoney of SUSE Labs, who is the current maintainer of reiserfs, sent me a patch that fixes the "continuous writes" caused by 'sync' command, and also fixes the "crash when Stopping array" bug as well.  This changes the landscape quite a bit and I'd like to release -rc15 with patched 3.9.6 kernel.

Wow your luck is turning up, good news for all, big thanks to Jeff!

Bring on RC15, don't forget all the xattr stuff you have added thus far (don't leave anything out  ).

[limetech]

There is an UPDATE! - please refer to the bottom of the first post in the thread.

 

Wow that is awesome.  Is there a short version explanation of what the patch patches?  Just for those of us who are curious.  Of course don't spend more than 5 mins writing it, pushing rc15 is way more important.

You can see one post he made to the newsgroup here:

http://thread.gmane.org/gmane.comp.file-systems.reiserfs.general/24257

 

He has not posted the patch there yet, but what it does is back out the changes he talks about.  I have also studied the patch and it does the right thing.