unRAID Server Release 5.0-rc13 Available


Recommended Posts

I now have a problem with AFP.  In short, after a clean reboot, I cannot connect to my unraid server from my imac via AFP.  This worked fine in the past.  I have found that if I disable AFP and then enable again, it starts working and I can connect.  It seems to work until I reboot, where I have to disable and then enable again.

 

I don't have time to grab the syslog right now, but wanted to see if anyone else has this same problem.

 

Running the OS X maintenance script fixed this for me. In my case it was a caching issue. Paste the below command into Terminal, it will require your admin password:

 

sudo periodic daily weekly monthly

Link to comment
  • Replies 341
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

As a matter of interest, by this morning, the Movies share can be accessed without problems - I guess that something had performed an automatic umount in the meantime.

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.

 

 

Link to comment

I got hit with this shutdown issue with rc13 this morning. [...] I could not access it after that. I had to manually force a shutdown on the machine by holding the power button.

 

My experience, exactly. It happened to me during all shutdowns. This morning after several reboots I gave up and copied RC12a to my sticks and everything's fine again.

Perhaps only few people are seeing this, but something is broken, definetely.

 

In this thread somebody asked why it's neccessary to shutdown unRAIDs at all. Here in Germany I pay ~0.30 EUR/kWh. According to my powermeter my two machines draw 440W/h --> 4 EUR/day. That makes over 1,400 EUR/year and that's the price of a new unRAID machine - every year.

 

Link to comment

As a matter of interest, by this morning, the Movies share can be accessed without problems - I guess that something had performed an automatic umount in the meantime.

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.

 

 

Please don't completely remove NFS support for user shares. It's working fine for me for XBMC and I don't want to have to rebuild my entire library. Plus, I've had issues with SMB and XBMC.

Link to comment

I now have a problem with AFP.  In short, after a clean reboot, I cannot connect to my unraid server from my imac via AFP.  This worked fine in the past.  I have found that if I disable AFP and then enable again, it starts working and I can connect.  It seems to work until I reboot, where I have to disable and then enable again.

 

I don't have time to grab the syslog right now, but wanted to see if anyone else has this same problem.

 

Running the OS X maintenance script fixed this for me. In my case it was a caching issue. Paste the below command into Terminal, it will require your admin password:

 

sudo periodic daily weekly monthly

 

Does that command have anything to do with flushing cache? I never used it before (thanks for the info).

 

I would think for cache it would be more in the lines of:

 

sudo launchctl unload /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
sleep 5
sudo launchctl load /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

 

 

"jaybee", believe me when I tell you, that you and me are not the only ones to feel this way, some are more reserved/hesitate, etc... each in there know right. I have been trying to get AFP working right of a very long time. I am close, but without Tom making some changes, it will be impossible. I agree that he needs to work on the greater good, but AFP/NFS where key aspects early on in 5.0. but just soooo much time gets lost with no changes and requests that have been made repeatedly. Take for example JoeL. asking what happened to the OOM value tweaking, no response. That is the kicker. If Tom would just answer, oops I forgot/ or damn missed that one, next round promise, or thought about it not a good idea. Thats what makes it human and understandable. These immense waiting periods with constant repeating is very hard to swallow. I have a laundry list, but just utterly tired to restate the same, none of it goes acknowledged (whether it be Nope I'm not doing that, would be something).

 

Piling up more features like btrfs is more hurtful than good. What's it 5.0 should be resolve to this best as possible. So much code (cache pools) was poured into making that happen I bet. Yet what was change for AFP as an example? The remove xattr is a great find and fix, but it that really all? why not a netatalk update?

 

What would happen if unRAID stayed on the say Beta12a kernel and port all those code changes up to RC10a into that kernel, would that make people happy as a 5.0 Final, it may...

To me it seems that the linux kernel people don't sit and work off of unRAID boxes and see how it affects unRAID, this is no way the entire linux community has all these problems and yet swears linux rocks. So it's like a crap shoot each time unRAID get a new kernel update. Maybe its time to take 2 steps back to move one step forward. Heck the additional wait time is irrelevant at this point, if it would accomplish a decent 5.0 final.

 

 

Link to comment

I now have a problem with AFP.  In short, after a clean reboot, I cannot connect to my unraid server from my imac via AFP.  This worked fine in the past.  I have found that if I disable AFP and then enable again, it starts working and I can connect.  It seems to work until I reboot, where I have to disable and then enable again.

 

I don't have time to grab the syslog right now, but wanted to see if anyone else has this same problem.

 

Running the OS X maintenance script fixed this for me. In my case it was a caching issue. Paste the below command into Terminal, it will require your admin password:

 

sudo periodic daily weekly monthly

 

Does that command have anything to do with flushing cache? I never used it before (thanks for the info).

 

 

 

 

 

•Daily: deletes some temporary files, etc., and records various statistics.  On older versions of OSX, some log files are "rotated," but in newer versions that's been moved to another process. 

•Weekly:  rebuilds some system databases.

 

•Monthly:  rotates some minor log files, records user statistics.

Link to comment

I got hit with this shutdown issue with rc13 this morning. [...] I could not access it after that. I had to manually force a shutdown on the machine by holding the power button.

My experience, exactly. It happened to me during all shutdowns. This morning after several reboots I gave up and copied RC12a to my sticks and everything's fine again.

Perhaps only few people are seeing this, but something is broken, definetely.

 

I just had my first encounter with this new bug. I upgraded this morning; my first round was without plugins and array not auto-started. So far, go good.

 

I brought the array down, powered down and re-enabled plugins; things seemed to be OK. I might have rebooted once after without incident. Later in the day, after not much activity on the server I tried stopping the array and then lost the touch with it. Like others have reported, unresponsive...no web, no putty, no local screen video, no keyboard response. I had to force it off with the power button.

 

I bailed on rc13 and went back to rc12, rebooted and was greeted with the system going into its own parity check (400+ minutes to go!). I'm attaching a Syslog. I don't know what to make of it, but I'm not too thrilled about troubleshooting it or jumping forward to rc13.

 

Cheers!

syslog-2013-06-05.txt

Link to comment

and the screen capture

 

I just had a screen capture that looked very similar to this after initiating a stop from the gui. I do have Simplefeatures installed and so far on reboot all is good and I did force a stop at least once more now without issue.

 

Link to comment

unprofessional post deleted

It's been a long week, man.

 

A very generous offer, but I'd suggest you retract it !!    UnRAID 4.7 is the "official" release even today, and is a rock-solid product as a storage server, which is what it's sold as.    And even the v5 RC's are generally very solid except for certain sets of hardware, which you've worked very hard to rectify, when you could have very easily simply added them to the "not supported" hardware list.

 

As for issues with various plugins and add-ons ... NOT your problem !!    Folks will always modify technology gadgets ... but doing so is at THEIR risk -- not the providers.    Consider how many phones, routers, game consoles, etc. that have developed entire communities dedicated to modifying them to do other things !!    Nobody expects to go back to the manufacturer to resolve any problems these mods produce  :)

 

One very valid complaint on this forum, however, is your VERY bad record r.e. status updates  8)

Link to comment

These RC candidates seem to be going backwards, to many kernel changes etc. and are more like beta releases. I really regret buying this product. I find I'm using netflix far more than my unraid server.

 

I'm looking at the parts in your signature, you seem to have zero parts that are even affected by the current issues. What are you even complaining about? At least state your problems before going on a rant so something can be done about them. It seems to me like you just prefer Netflix over having to manage your own server. That's not unRAIDs fault at all.

 

I have 2 very large unRAID servers that contain some "problem" parts with 5.0, and they cost me nearly 2 grand (not even including the whopping 86TB in hard drives). I am happy 5.0 did not go final before these issues were fixed, if it did i'd feel like people with these parts were given up on. For everyone else, 5.0 is working PERFECTLY! So what's your problem, other than you prefer Netflix to a physical server? It really ticks me off when people who seem to have 0 issues just come on here to complain that it's not "final" yet.

Link to comment

Please run the script attached to my previous post, and then try to crash your server, so we can look in the syslog what really happened.

Barzija,

Thanks for putting the script together! Am I correct to assume I need to chmod it to 755 (make it executable)? Also, since I'm running a parity check now is it safe to cancel it. I won't have much time to troubleshoot in the next day or so, but I will give it a go. I appreciate the help! I would like to get rc13 running.

 

Link to comment

A quick question to limetech...

 

I noticed that now we are mounting the md devices with "user_xattr,acl" options.  Does that have something to do with NFS or with AFP?  And if not, wouldn't it bring some speed benefit if we mount them with "nouser_xattr,noacl", like we used to do?  Thanks.

 

I remember this question being asked in the past and Tom answering it, the short off it is yes extended attributes need to be supported. He can explain in the technical terms.

 

 

Tom you can vent/slip/whatever, it's human and you're replying and its appreciated. Good, bad doesn't matter. I say this wholeheartedly. Grab a beer, go outside and kick something! Then let us know where we are going.

 

Link to comment

These RC candidates seem to be going backwards, to many kernel changes etc. and are more like beta releases. I really regret buying this product. I find I'm using netflix far more than my unraid server.

 

I'm looking at the parts in your signature, you seem to have zero parts that are even affected by the current issues. What are you even complaining about? At least state your problems before going on a rant so something can be done about them. It seems to me like you just prefer Netflix over having to manage your own server. That's not unRAIDs fault at all.

 

I have 2 very large unRAID servers that contain some "problem" parts with 5.0, and they cost me nearly 2 grand (not even including the whopping 86TB in hard drives). I am happy 5.0 did not go final before these issues were fixed, if it did i'd feel like people with these parts were given up on. For everyone else, 5.0 is working PERFECTLY! So what's your problem, other than you prefer Netflix to a physical server? It really ticks me off when people who seem to have 0 issues just come on here to complain that it's not "final" yet.

 

Actually it's comments like this that are my problem, I have a life and I don't want to spend it on these forums hoping for an update to fix my minor issues (obviously not major problems like yours).  Tom has refunded my money so I will complain no more.

 

 

 

 

 

Link to comment

Limetech, keep up the good work.  I know there's a lot of people complaining/ranting/bitching in this thread instead of posting helpful reports and experiences.  I've been following it to see if I should update my production server or hold off.  Instead there are way too many people complaining about specific issues they're experiencing which don't affect me (or likely 95% of unRAID users).  I personally love your product, have 2 Pro licenses (even though I only use one), and am always eager to see what the next release will hold.  I also appreciate the recent moves to keep the community better informed.  It's a great community, and I'm sure it's because of the fact that many of us are so loyal and use your product daily that sometimes people get passionate about their concerns.

Link to comment

 

....don't have unRAID running since a long time ;-)

 

 

What do you use then?

 

ZFS on a Solaris 11 box...I left unRAID because I needed FullDiskEncryption (Where I am limited to LUKS or Solaris for external compliance reasons)

 

i have two virtualized unraids and one virtualized solaris 11, with an encrypted zfs zpool ... i'm not too crazy about the write speeds on the zfs box, but i'm using it just a backup dump

Link to comment

A quick question to limetech...

 

I noticed that now we are mounting the md devices with "user_xattr,acl" options.  Does that have something to do with NFS or with AFP?  And if not, wouldn't it bring some speed benefit if we mount them with "nouser_xattr,noacl", like we used to do?  Thanks.

 

I remember this question being asked in the past and Tom answering it, the short off it is yes extended attributes need to be supported. He can explain in the technical terms.

 

Tom you can vent/slip/whatever, it's human and you're replying and its appreciated. Good, bad doesn't matter. I say this wholeheartedly. Grab a beer, go outside and kick something! Then let us know where we are going.

 

I remember this question being asked in the past, but I have not seen Tom answering it. And since you are not providing a link to such answer, then how is your post helpful?  And are you telling Tom to ignore my question?  The "He can explain" part was the reason I directed my question to him in the first place.

 

Peace man.  Those mount options were added quite some time ago, I can go research it, but it was put in to support Active Directory, then later netatalk (AFP) wants extended attribute support as well.  I'm not sure about the speed benefit, seems to me it wouldn't affect speed at all.  If you know something different, please let me know.

Link to comment
UnRAID 4.7 is the "official" release even today, and is a rock-solid product as a storage server, which is what it's sold as.

 

Unfortunately that's not true.  There are at least three known bugs in 4.7 which compromise data integrity.

Link to comment

Tom you can vent/slip/whatever, it's human and you're replying and its appreciated. Good, bad doesn't matter. I say this wholeheartedly. Grab a beer, go outside and kick something! Then let us know where we are going.

Appreciate it man, thank you.

 

About an hour ago, I set up a test server and sat at the webGui click Stop then Start then Stop then Start ...., and what do you know, it did generate a crash after about 50 clicks.  So I'm drinking a home brew and trying to analyze wtf is going on.

Link to comment

Limetech, keep up the good work.

 

Agreed! Although I'm committed to using nfs (both technical and emotional reasons - I don't use Windows at all), and affected by the stale file handle problem, I am still very keen to carry on using unRAID v5.

Link to comment

A quick question to limetech...

 

I noticed that now we are mounting the md devices with "user_xattr,acl" options.  Does that have something to do with NFS or with AFP?  And if not, wouldn't it bring some speed benefit if we mount them with "nouser_xattr,noacl", like we used to do?  Thanks.

 

I remember this question being asked in the past and Tom answering it, the short off it is yes extended attributes need to be supported. He can explain in the technical terms.

 

Tom you can vent/slip/whatever, it's human and you're replying and its appreciated. Good, bad doesn't matter. I say this wholeheartedly. Grab a beer, go outside and kick something! Then let us know where we are going.

 

I remember this question being asked in the past, but I have not seen Tom answering it. And since you are not providing a link to such answer, then how is your post helpful?  And are you telling Tom to ignore my question?  The "He can explain" part was the reason I directed my question to him in the first place.

You are right! WOrthless post on my part. I was (in my mind) buying Tom some time to answer while he was outside kicking something.

I would have posted the link, but didn't know which thread its buried in, sorry for that. But he did answer this I know this for a fact. I know worthless thought. My bad.

 

Link to comment

....

 

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.]

 

....

 

Without getting into this too much, I'll just list the reason I use NFS on my OpenELEC box: the CPU utilization is noticeably lower and the throughput higher. Doesn't matter on most OpenELEC or XBMC machines, but is important for the ones with weaker CPUs such as the ARM-based ones. This is also true of many media streamers that use ARM CPUs.

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.