unRAID Server Release 5.0-rc6-r8168-test Available

[Joe L.]

UPDATE: I left everything as-is last night (with the webgui hanging and all), slept 7 hours, and woke up this morning to find the webgui loading fine.  Syslog attached.

You are on unRAID 4.7and the shares were configured shortly after you started back up according to the syslog.

 

Please follow up in the general support forum.  This has absolutely nothing to do with the rc6-test version of unRAID.

[wheel]

Sorry, wrong syslog - believe it or not, I'm juggling two towers simultaneously (one 4.7, one r8168-test), and both are giving me headaches at the moment (see General Support for the other thread).

 

Here's the r8168-test syslog:

syslog.txt

[Helmonder]

Enter "lsof /mnt" to see open files. The pre-clear did cause the problem due to low memory.

 

My array will not shut down after I have told it to.

 

WARNING: Only do this if you are comfortable with linux commands, if not, wait it out and if all else fails reset the system (this will result in a parity check)

 

1. Telnet into the system.

2. Do a ps -elf | grep mnt and see if something recognisable is still at work

3. If not try ps -elf | grep disk and see if something recognisable is still at work

4. KILL <processid> (the number at the start of the line giving the ps -elf results)

5. Wait if array shuts down, if not, back to 2

6. Also worth trying: ps -elf | grep forked (the itunes plugin (forked-daapd) does this standard, I have to do it every time)

[S80_UK]

Ok, I wasn't sure if this issue was related to the new rc6 release or not.  Which forum should it be in then?

 

The General Support forum would be the place.

[optiman]

Ok, I wasn't sure if this issue was related to the new rc6 release or not.  Which forum should it be in then?

 

I setup my server back in 2009 and I don't recall ever having to do anything with a key.  That said, your reply makes sense to me.  I just now need to confirm that was the issue.

 

Thanks for your reply.

 

All, just for the record, this was my bad on the new flash drive and had nothing to do with this release.  Tom sent me a new key and all is good again.  Time to swap a very old hard drive today, so hope that goes well.

 

I've rebooted about 8 times now and went through everything, can't find anything wrong.  I think we are extremely close to calling this FINAL.

 

Awesome work guys!

[savestheday]

Ok, I wasn't sure if this issue was related to the new rc6 release or not.  Which forum should it be in then?

 

I setup my server back in 2009 and I don't recall ever having to do anything with a key.  That said, your reply makes sense to me.  I just now need to confirm that was the issue.

 

Thanks for your reply.

 

All, just for the record, this was my bad on the new flash drive and had nothing to do with this release.  Tom sent me a new key and all is good again.  Time to swap a very old hard drive today, so hope that goes well.

 

I've rebooted about 8 times now and went through everything, can't find anything wrong.  I think we are extremely close to calling this FINAL.

 

Awesome work guys!

 

I think a lot of LSI users would disagree

[peter_sm]

@Tom

 

Can you add this "sensor" to next version i2c-piix4

 

//Peter

[PeterB]

I think we are extremely close to calling this FINAL.

 

Awesome work guys!

 

I think a lot of LSI users would disagree

 

Do you know of any LSI users who are still having problems with rc6-r8168-test2?  I haven't seen a message from anyone who's tried that version and still had problems.

[optiman]

HD swap went just fine with this release, parity rebuild did just what it needed and all continues to be good.....are we FINAL yet?

 

I agree with PeterB, I don't see much complaining going on right now.  This release seems very solid to me.

[yp_1]

Is somebody using NFS with this release?

I upgraded and NFS seems to be broken (saw something like nfsd unknown error -107 in syslog).

RC5 works fine.

[Frank1940]

Is somebody using NFS with this release?

I upgraded and NFS seems to be broken (saw something like nfsd unknown error -107 in syslog).

RC5 works fine.

 

Working fine on my system and I have not seen any reports of NFS problems that were related to this release.  You had best post more details of your exact problem and a complete syslog. 

[BRiT]

There may be a slight waiting game with the LSI issues to see if there will be an official fix from the Linux devs. It's quite an odd issue in the commit change that causes the issue to show up isn't directly related to it, but perhaps it was masking some other underlying bug.

 

Or maybe there's the thought of trying out the latest Linux 3.5 kernel though perhaps that should be the first item going into the 5.1 release.

[PeterB]

Is somebody using NFS with this release?

 

Yes, I only use NFS, no Samba or AFP here.

 

I upgraded and NFS seems to be broken (saw something like nfsd unknown error -107 in syslog).

 

I've not experience any problems.  What were the circumstances which provoked this error?

 

A quick google suggests that the textual description of 107 is 'peername failed'.  I'm not quite sure what that means in terms of nfs.

[PeterB]

There may be a slight waiting game with the LSI issues to see if there will be an official fix from the Linux devs.

 

I understood Tom to say that he would use the current fix/workaround to get the new release out, until an official fix is produced by the devs, and that he would backport the fix to whatever kernel unRAID is using at that time.

[yp_1]

Is somebody using NFS with this release?

 

Yes, I only use NFS, no Samba or AFP here.

 

I upgraded and NFS seems to be broken (saw something like nfsd unknown error -107 in syslog).

 

I've not experience any problems.  What were the circumstances which provoked this error?

 

A quick google suggests that the textual description of 107 is 'peername failed'.  I'm not quite sure what that means in terms of nfs.

 

 

Sorry, I replied quoted wrong message. Here it is again.

 

I can't reproduce the error anymore. But there are 5 nfsd threads running in interruptible state (D) blocking IO and causing LAVG of 12 on my dual core system.

Definitely a problem. I don't run anything special on NFS - just backup my ESX VMs by copying their snapshot to a NFS mounted datastore. The problem never existed before and I assume it is specific to the newer kernel. Since ther is nothing in the logs at this point I don't know what else can be done to determine a problem.

 

root@Tower:/var/log# ps ax|grep nfsd|grep D

10387 ?        D      0:24 [nfsd]

10388 ?        D      0:24 [nfsd]

10390 ?        D      0:24 [nfsd]

10392 ?        D      0:25 [nfsd]

10393 ?        D      0:23 [nfsd]

10394 ?        D      0:25 [nfsd]

 

root@Tower:/var/log# vmstat 2

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----

r  b  swpd  free  buff  cache  si  so    bi    bo  in  cs us sy id wa

0  5      0 131088  92516 3631040    0    0    13  1461  888 1038  0  4  7 89

0  5      0 131080  92516 3631040    0    0    0    0  205  66  0  0  0 100

0  5      0 131080  92516 3631040    0    0    0    0  206  64  0  0  0 100

[optiman]

sllighly off topic...sorry

 

I was using only NFS with 4.7, then when I went to v5 I just used the default and only working solution - SMB, at the time.  It seems that all NFS issues are now resolved, but I haven't seen any reason to switch back.  Is there really any advantage of using NFS over SMB anyways?  My pch, mobile, and my win7 pc have no issues with SMB.

[Frank1940]

sllighly off topic...sorry

 

I was using only NFS with 4.7, then when I went to v5 I just used the default and only working solution - SMB, at the time.  It seems that all NFS issues are now resolved, but I haven't seen any reason to switch back.  Is there really any advantage of using NFS over SMB anyways?  My pch, mobile, and my win7 pc have no issues with SMB.

 

I have read that many people 'feel' that NFS has less overhead than SMB and, therefore, has a higher transfer rate than than SMB.  On clients with slow processors or high utilization of CPU cycles, this lower overhead (as an example) could result in smoother playback with fewer, or no, hitches in the media stream.  SMB has been (and is continuing) to receive considerable development effort in the Linux community.  In all probably, there is probably little difference between NFS and SMB in the most recent kernel releases.  However, if you have a media player with a slow CPU that uses an older kernel, NFS may work better for you. 

[optiman]

thank you sir!  That was well explained. 

[savestheday]

I think we are extremely close to calling this FINAL.

 

Awesome work guys!

 

I think a lot of LSI users would disagree

 

Do you know of any LSI users who are still having problems with rc6-r8168-test2?  I haven't seen a message from anyone who's tried that version and still had problems.

 

I didn't see test2 till after I posted this comment.  Can't wait for the fix to come out cause I've got two drives ready to expand!

[Frank1940]

I think we are extremely close to calling this FINAL.

 

Awesome work guys!

 

I think a lot of LSI users would disagree

 

Do you know of any LSI users who are still having problems with rc6-r8168-test2?  I haven't seen a message from anyone who's tried that version and still had problems.

 

I didn't see test2 till after I posted this comment.  Can't wait for the fix to come out cause I've got two drives ready to expand!

 

If you are willing to assist in testing this release, you can find a link to it in the first post of the following thread.  No one has had a problem with it thus far.  Note that this thread was also used of the first test which was not successful.

 

http://lime-technology.com/forum/index.php?topic=21597.0

[savestheday]

I think we are extremely close to calling this FINAL.

 

Awesome work guys!

 

I think a lot of LSI users would disagree

 

Do you know of any LSI users who are still having problems with rc6-r8168-test2?  I haven't seen a message from anyone who's tried that version and still had problems.

 

I didn't see test2 till after I posted this comment.  Can't wait for the fix to come out cause I've got two drives ready to expand!

 

If you are willing to assist in testing this release, you can find a link to it in the first post of the following thread.  No one has had a problem with it thus far.  Note that this thread was also used of the first test which was not successful.

 

http://lime-technology.com/forum/index.php?topic=21597.0

 

To be completely honest, I'm running RC4 and it's stable. I've got a large array and don't want to chance it.  I may be building a second server soon so I can test it then but for now, I don't want to endanger my prod environment (yes I know this isn't final software but RC4 is very stable for me!).  I'm a tinkerer at heart so it pains me to even write that but I've got 32TB of data that tells me otherwise

[PeterB]

To be completely honest, I'm running RC4 and it's stable. I've got a large array and don't want to chance it.  I may be building a second server soon so I can test it then but for now, I don't want to endanger my prod environment (yes I know this isn't final software but RC4 is very stable for me!).  I'm a tinkerer at heart so it pains me to even write that but I've got 32TB of data that tells me otherwise

 

I wonder what encouraged you to go to RC4, then?

 

There are already several people running RC5 and RC6.  There have been some significant fixes since RC4 - virtual elimination of NFS 'stale file handle errors', elimination of a significant cause of duplicate files etc.

[savestheday]

To be completely honest, I'm running RC4 and it's stable. I've got a large array and don't want to chance it.  I may be building a second server soon so I can test it then but for now, I don't want to endanger my prod environment (yes I know this isn't final software but RC4 is very stable for me!).  I'm a tinkerer at heart so it pains me to even write that but I've got 32TB of data that tells me otherwise

 

I wonder what encouraged you to go to RC4, then?

 

There are already several people running RC5 and RC6.  There have been some significant fixes since RC4 - virtual elimination of NFS 'stale file handle errors', elimination of a significant cause of duplicate files etc.

 

PeterB,

I started on 5.0 beta 6, I never had 4.7.  I waited till unRAID supported AFP (I have 5 Macs in my house) and the LSI cards (and of course was somewhat stable).  unRAID has been very stable for me for the past year (save some AFP issues).  While I started out using it in a test environment, I have, probably against the better judgement of most, used unRAID 5.0 beta/rc as a prod environment for quite some time now. 

 

I also have a similar build to JohnM and since I know he tests every new release, I usually wait for the all clear from him.  I've even communicated with him through PM about upgrading to certain beta and RC releases.  He's been very helpful.

 

So RC5 is definitely doable for me but till this point, RC6 has had LSI issues.  I've stayed on RC4 because it's been stable and I don't use NFS. 

[PeterB]

So RC5 is definitely doable for me but till this point, RC6 has had LSI issues.  I've stayed on RC4 because it's been stable and I don't use NFS.

 

Okay, but RC6-test2 has fixed the LSI problem - I'm now using it with my data drives attached to an LSI controller. As far as many are concerned, test2 has brought us very close to a releasable build.

 

What I would advise, though, is to make sure that you're running the latest (P14) firmware on your LSI card.  It incorporates a lot of fixes around status commands and standby/sleep state.

[HiSoC8Y]

hello

 

I have an old PC, with 2 HDD (1 IDE and 1 SATA), and the NIC is (RTL8110SC / 82684S1)

 

I tried this version of unRAID (5.0-rc6-r8168-test), but it did not detect my NIC, I was getting "lo" when i was trying ifconfig eth0.

 

I then went and tried this version of unRAID (5.0-rc5 AiO), and it worked.

 

Just thought of reporting this issue.