jaybee

Where's 5 final? Must be time now.

So Tom, how's it looking in your opinion RC16C? The best candidate yet for 5 final release? ETA for 5 final?

OK read the thread now, admitedly skim read. Would it be fair to say that there are two issues in here that for some reason wondered off from the RC16C thread. 1: Freezes during movie playback if a disk spins down 2: ESXi issues with spindown With number 2... that's surely not something that should be delaying a 5 release? i.e. How XYZ works under ESXi? With 1, sounds like some investigation is required.

I'm really sorry to post this in here and I know this will come accross as rude, but can someone sumarize the problem here for me as I do not have time to read this whole thread. I will tomorrow. Is it going to delay 5 release?

Nice work Tom. This is feeling like it will never end though with these RC's. I agree with earlier comments that dual parity should be a priority over other things we can already achieve via plugins like UPS/Email support. Otherwise, it would be good to see this thread stay on topic of testing this RC16C release with no addons.

I don't understand what you guys are saying about the way free space is calculated. Can someone explain it in more detail? I expect to see info on how much disk space is free per disk. Others seem to expect it to show something different?

Could this be the fix that was put in for the file system that has caused an issue?

Get updated version of SF. one or more of your plugins is probably out-dated. It is my understanding rc16 will be out soon (a handful of us are running rc16 in a limited trial), so wait a bit any try again with it after updating your SF installation. Joe L. Why do we need an RC16?

Make sure when you put it to sleep you wait a couple of minutes for it to fully sleep. Also when you bring it up, be sure to not try to access webgui for a few minutes and see if this helps. Can you retest and let us know having done this? I had a similar problem with RC14 or RC15 the other day where I had to wait a while for webgui to respond, although it may have been a fluke. EDIT: More info. When my server did this it was still accessible via telnet and emhttp process was running ok. If I recall correctly I think eventually one of the plugins either unmenu or simplefeatures DID come up, and the other did not. I rebooted and tried to sleep and resume again this time giving more time for things to come up without immediately trying to access, and it worked ok.

It's a plugin issue? I only have two things I have installed as I have been waiting for 5 to go final before really jumping on board so I am relatively new to it. I have literally only loaded unmenu and simplefatures that I can think of. I have barely got through the installation/configuration guide so there is nothing "hardcore" running at all. I would classify SF as hardcore.. If it's the amount of people that use it, or the complexity of this plugin, but the number of problem threads I've read on this forum which could be traced back to SF is very large in my opinion. Not to discredit the makers ofcourse Just try it without SF and post your results... Oh ok. What about unmenu? I consider having at least one of these two installed as mandatory for my needs in terms of what I would call acceptable levels of control, management and configuration via the webgui. But of course I understand the need to test with nothing installed to help.

Nice thread. Can we see some "real world" results. What is the speed difference between: a) Writing a 10gb file to the server. b) Doing a full parity sync/calculation. That would be great.

It's a plugin issue? I only have two things I have installed as I have been waiting for 5 to go final before really jumping on board so I am relatively new to it. I have literally only loaded unmenu and simplefatures that I can think of. I have barely got through the installation/configuration guide so there is nothing "hardcore" running at all.

I have the same problem and my server takes ages to get to the logon prompt after this. Tom, anyone, what it the recommendation for this problem? Await RC16? Edit something? Modify USB stick files?

Cool yep. Figured it out. Will try booting now. Thanks

I tried to boot my machine and a DIMM went bad, so now I am down to a single stick of 2gb ram. So all the talk of the 4gb memory limit and parameters, well, with RC14 if I try to boot up with 2gb of ram it does not work. It uses the default option of course with 4gb limit and it does not boot. It loops back to POST. If I take the other option it boots ok. So how can I make it default to the other option? Why does it not work on default option? Do I need to change some option in my BIOS to do with memory mapping? The default is that it is set to ENABLED in my BIOS. I think this is an option for 32bit OS's to be able to use 4gb or more. Confused. Off to modify syslinux.cfg file and/or remove it.

Great news!

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. There are times when we have to simply say, that's not supported anymore because it's too old. Sorry. I would like to see a poll as to who can afford to run unraid and keep purchasing disks and media to store, but cannot update their system to hardware capable of running 64bit. I would suspect the percentage would start with a zero.

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. 2: Will licences bought for 32bit version be transferable to 64bit version? 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? 4: What approximate ETA would you set yourself for having 5 final right now? 5: What approximate ETA would you set yourself for having 6 released into the wild for testing? Tom I'm happy to see you getting close with 5. One final push and it's there surely. I keep getting frustrated with you and unraids problems, but there is nothing else that fits my needs at all. NOTHING. There are competing technologies and setups that I have personally looked into myself and yet I keep coming back to unraid armed with my pro licence ready to install and use 5 final because nothing else compares. Every single other option I look at has something I don't like about it. Unraid is perfect if it could go final with no issues and the icing on the cake would be to sort NFS issues. Keep up the good work.

So someone confirm what I need to do in order to boot and test RC14. My machine has 4GB of ram installed, no more, no less. I think the answer is nothing, but if I want, I can edit the file talked about earlier with the dollar sign in front of a php variable. Correct?

RC14 AVAILABLE

Hi, Do you consider the problems reported so far in this thread to be "show stoppers" ? Does the above still stand true in that RC13 will be renamed to final in "a matter of days"?

Can we have a summary of outstanding issues with version 5? - NFS - Slow write issue on some setups? < fixed? - Slow/non responsive GUI at times - Increased and infinite write issue

What's the final status then? Now working? Probably the sequence that needs to happen is something like this: 1. un-mount all NFS shares on each client machine 2. create the extra.cfg file with the line shfsExtra="-o noforget" 3. stop/start array for step 2 to take effect 4. re-connect (re-mount) shares on client machines. Now as long as server is not reset, shutdown, or array stop/started, NFS should not get stale file handles. But if server is reset/shutdown/stopped, then you should also un-mount/re-mount shares on client side as well. Probably should use 'soft' mount option on clients as well. I am still confused if this addresses the issue I have seen here: http://lime-technology.com/forum/index.php?topic=27720.msg244928#msg244928 If so, I leave my OpenELEC system on 24/7. Every time I restart unRAID, that means that my OpenELEC machines will no longer be able to reach my media shares unless I unmounts/remount the NFS shares??? I hope this is not the case. I really don't want phone calls from my wife saying that she is unable to put a movie on for my two young boys who are driving here bonkers. John I think we are going to need to start a separate discussion about NFS... What I'm going to have to do is disable NFS access for user shares (but not disk shares). In a nutshell the issue is that NFS requires a persistent "handle" associated with every file system object that is unique and doesn't change as long as that object exists, and is never re-used once the object is deleted, and persists across server resets. The 'noforget' option talked about meets these requirements, at cost of incrementally increasing memory footprint, with the exception of "persistence across server resets", which is a killer, unfortunately. PeterB I know you are going to ask, "why does it work with -rc10"? The answer is, "by accident". Eventually it won't work, or worse (meaning client tries to read fileA and gets contents of fileB instead). How to workaround? Use SMB instead of NFS for user share access. SMB (actually SMB2, soon SMB3) is pretty good these days, so I would ask, why use NFS with OpenELEC? I use SMB for all media clients, including OpenELEC, without any issues. [Actually for OpenELEC and XBMC you could associate all your disk shares with Movies or TV, etc if you're really keen on NFS.] Can this issue be fixed? Of course all issues can be fixed and all features can be implemented - it's just a matter of time and resources. For example, look at AFP. AFP is very similar to NFS at the protocol level. Instead of "file handles", AFP uses "cnid's", but it's the exact same concept (actually it's even far more restrictive than NFS handles). How does netatalk solve this? By using a full-blown database to store cnid-to-filename mappings. Can I do this with user shares to support NFS? Sure, but does it make sense for me to put off all other development to implement this feature? Hard to justify it. There are a couple other possible solutions: a) use NFSv4 which has concept of "volatile" file handle. Read about it here: http://docs.oracle.com/cd/E19082-01/819-1634/rfsrefer-137/index.html b) use a user-space NFS server. There are a few user-space NFS server projects out there, without a lot of traction though. Here's what I ask. After reading this, go outside and kick something and then let's talk about this in an objective manner. Probably the solution is to use NFSv4. How much work is it to "use NFSv4" ? I'll tell you where I'm at with unraid since Tom, you state you welcome any replies. I feel as a user that has been following it and paid for a full pro licence a while ago, that I am still waiting for the product I paid for. I know this will sound harsh, but when I bought it I did not realize v4.7 had major bugs that could cause data loss. So I discussed this on here and it was generally accepted that v4.7 was over in terms of development and that version 5 was worth waiting for as that was where all the work was being done. I've patiently watched and waited for 5 final for...well...1-2 years now, and I'm just not happy about really using it anymore as I have lost all confidence in it. I need NFS to work. I do not have time to try all of the RC's sadly, so have just been trying to keep up with threads about all the various issues and mostly NFS. NFS simply does not work reliably. That's just a fundamental flaw. It's not unacceptable to require NFS as mentioned above. All the time it has taken and then we get some updates about 5 FINAL being around the corner. Well...the name of the most current version 5 unraid software may be changing to final, but it's not a final product. It's another Beta product we are expected to use in a prod environment. Call it an RC. Call it "FINAL". It's not complete. You have not given enough time to iron out any bugs before you simply rename it as FINAL. Why did you wait all this time to suddenly have to have it finished within a week with a FINAL name? I suppose the answer is so that the new hardware products you are selling will ship with a version 5 "FINAL". Every time we get an RC thread it reminds me how compatability with any plugin is not guaranteed nor recommended to be ran at all. I feel like running an unraid server is just too stressful if you want piece of mind that it will all work nicely and protect your data. Am I being over the top? Quite probably. I'm just saying these are the feelings I get when looking at the product, which is a shame. I have lost all enthusiasm for it. I'll await for the replies telling me a) how long they have been running unraid with no issues, and b) how no software is bug free.

Is the slow write performance fixed in this then? Anyone seen the problem appear in this release? Also, Tom, what is this "better fix" that will come in the future for NFS stale file handle?

So you went with Synology because of performance basically. Ok. That's fair enough. I think the only advantages I can see are: - RAID6 if you want dual drive redundancy (which also has the disadvantage of...errr... being RAID6 - Nice, slicker, intuative GUI ? (guesses) - Stable ? - Better write performance - "Just works" in that it is more "plug and play" and simplified. (also a weakness)