unRAID Server Release 5.0-rc13 Available


Recommended Posts

  • Replies 341
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

I have this settings when started up my server ..... so definitely the WOL should have been working like it was on RC12a

 

NIC info (from ethtool)
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes:   10baseT/Half 10baseT/Full 
                        100baseT/Half 100baseT/Full 
                        1000baseT/Half 1000baseT/Full 
Supports auto-negotiation: Yes
Advertised link modes:  10baseT/Half 10baseT/Full 
                        100baseT/Half 100baseT/Full 
                        1000baseT/Half 1000baseT/Full 
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                     100baseT/Half 100baseT/Full 
                                     1000baseT/Full 
Link partner advertised pause frame use: Symmetric
Link partner advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
Link detected: yes

 

Peter ---

 

Why not try this command as 'nars' suggested to see if it helps:  ethtool -s eth0 wol g 

 

Remember that one of the changes that Tom made in rc13 was to use the stock Linux realtek drivers rather than the drivers that Realtek provides.  (I understand that the Realtek drivers are proprietary and hence the Linux folks will not include them in their releases.)  Apparently, the stock Linux realtek drivers work for most things but perhaps not for WOL.  Someone has suggested that wol may be turned off in the stock driver and you could quickly determine if this is the case...

Link to comment

Guys FYI on the NFS Stale handles issue .... I think there is a tangent going on here ..... most of the

 

"emhttp: get_filesystem_status: statfs: /mnt/user/ftp Transport endpoint is not connected"

 

error messages are reported by *plex* media center plugin users!

 

The problem occurs whether you run NFS or not!

 

The problem is simple to recreate at will.

 

1). Unraid 5.0-rc13

2). PlexMediaServer-0.9.7.22.511-4b5280f-unRAID.txz

3). Create a photo album folder on a user share

4). dump about 100 photos in the user share folder

5). launch plex media web console and add the user share photo folder to your photo library and then watch while it index's\creates meta data.

6) tails syslog and just wait for fuse to go bonkers.

 

basically rc 13 is a lot better than 12

I did upgraded my HP Micro server from 2GB to 4GB of ram to see if it helped (it didn’t).

also all of the other suggestions

 

i). /boot/config/extra.cfg

ii). oom_score_adj = -1000 for the emhttp pid

 

did not make a blind bit of difference!

 

This is driving me nuts and stopping me taking this POC and buying  Pro version + cache drive to replace my Media Center.

Its also so easy to recreate ... just install plex and adds some music photos.

 

happy to do any debugging with what little spare time I have.

 

It must be something to do with fuse and a spike of files handles that are created when you add large number of files to the library.

I don’t know why this is just with photo's ..... music does not seem to be a problem.

 

Only difference ?

a). Size of files.

b). number of files in a folder (more in photo folders). 

 

Link to comment

Download | Release Notes

 

First, the so-called "slow write" issue with X9SCM motherboards and similar.  This seems to be fixed in the linux 3.9.x kernel series.

 

This is great news for the new X9SCM-IIF motherboard I just ordered.

 

I wouldn't really say that the so-called "slow write" issue is fixed. On my Supermicro X7DBE board with 16GB ram and stock RC13, my writes to the array are ~15MB/s. Reboot with the mem=4095MB option, and the writes go up to ~35MB/s.  So, at least we have a good workaround for now.  Pity for my wasted 16GB RAM though.  My guess is that this issue will only be really fixed when unRaid starts shipping with a 64-bit kernel as an option.

 

Edit: For further reading...

http://lime-technology.com/forum/index.php?topic=22675.msg244385#msg244385

 

 

Fixed it for me with my X9SCM-F/E3-1230v2/8GB of RAM allocated to VM. In the past I fixed it by issuing this command: "sysctl vm.highmem_is_dirtyable=1". I added to my go script, actually. After I upgraded to RC13 I removed it from my go script, rebooted and speeds were normal.

Link to comment

I installed -rc13 earlier this week on my HP Microserver. No issues so far.

 

I actually pre-cleared a new 4TB drive and then replaced my 3TB parity with it. Rebuilt at ~110MB/sec with no issues. I've also stopped and restarted the array several times during this process without the crashing that others are reporting. Looks good to me.

Link to comment

I wouldn't really say that the so-called "slow write" issue is fixed. On my Supermicro X7DBE board with 16GB ram and stock RC13, my writes to the array are ~15MB/s. Reboot with the mem=4095MB option, and the writes go up to ~35MB/s.  So, at least we have a good workaround for now.  Pity for my wasted 16GB RAM though.  My guess is that this issue will only be really fixed when unRaid starts shipping with a 64-bit kernel as an option.

 

Edit: For further reading...

http://lime-technology.com/forum/index.php?topic=22675.msg244385#msg244385

 

Fixed it for me with my X9SCM-F/E3-1230v2/8GB of RAM allocated to VM. In the past I fixed it by issuing this command: "sysctl vm.highmem_is_dirtyable=1". I added to my go script, actually. After I upgraded to RC13 I removed it from my go script, rebooted and speeds were normal.

 

So, your unRaid runs in a VM?  What speeds do we call "normal"?  Have you actually clocked your write speeds with and then without the mem=4095MB option on the same setup, so we can compare?  Try do that test with a bunch of files that in total exceed your installed RAM.

 

 

Speeds were 35-40MB/s to the array and 100MB/s+ to the cache with either mem=4095MB or sysctl vm.highmem_is_dirtyable=1. Without one of those being set I'd get around 3MB/s to the array or cache drive. I tested this a while back on RC12a. I used sysctl vm.highmem_is_dirtyable=1 since it didn't limit the amount of RAM. Since upgrading to RC13 I get those same speeds with neither option being set and having 8GB of RAM assigned to the array.

Link to comment

Guys FYI on the NFS Stale handles issue .... I think there is a tangent going on here ..... most of the

 

"emhttp: get_filesystem_status: statfs: /mnt/user/ftp Transport endpoint is not connected"

 

error messages are reported by *plex* media center plugin users!

 

The problem occurs whether you run NFS or not!

 

The problem is simple to recreate at will.

 

1). Unraid 5.0-rc13

2). PlexMediaServer-0.9.7.22.511-4b5280f-unRAID.txz

3). Create a photo album folder on a user share

4). dump about 100 photos in the user share folder

5). launch plex media web console and add the user share photo folder to your photo library and then watch while it index's\creates meta data.

6) tails syslog and just wait for fuse to go bonkers.

 

basically rc 13 is a lot better than 12

I did upgraded my HP Micro server from 2GB to 4GB of ram to see if it helped (it didn’t).

also all of the other suggestions

 

i). /boot/config/extra.cfg

ii). oom_score_adj = -1000 for the emhttp pid

 

did not make a blind bit of difference!

 

This is driving me nuts and stopping me taking this POC and buying  Pro version + cache drive to replace my Media Center.

Its also so easy to recreate ... just install plex and adds some music photos.

 

happy to do any debugging with what little spare time I have.

 

It must be something to do with fuse and a spike of files handles that are created when you add large number of files to the library.

I don’t know why this is just with photo's ..... music does not seem to be a problem.

 

Only difference ?

a). Size of files.

b). number of files in a folder (more in photo folders).

 

If you have time, this would help a lot:

 

First, do your steps 1 to 4 above.

 

Next, create the file 'config/extra.cfg' and put this line in there:

 

shfsExtra= "-logging 3"

 

Now Stop array and Start array.  From this point on shfs will output numerous lines of debugging data to the system log.

 

Do your step 5 to make error happen.

 

Post system log here or send to me [email protected]

 

To stop all the debugging output, delete the 'extra.cfg' file, or delete that line from it, and then Stop/Start array again.

Link to comment

Let's do something simpler please, forget about earlier RCs for a moment. Let's focus on RC13 only.  Also, forget about the dirtyable thing for now, just set it to 0.  Lets do something very simple: Clock your writing speeds without mem=4095MB option, and then clock the same thing with the mem=4095MB option. Same files, same disk you write to, same RC13, same everything.  That will be interesting to compare.  And, for the test, do it with the same group of files with total size of more than 10GB please.

 

(BTW, you mentioned "VM" earlier. Is your unRaid running inside a VM, or did you mean that you're running VMs on unRaid?  If your unRaid is inside a VM, then how much is the total RAM on the host, and how much of it is dedicated to the virtualized unRaid?)

 

I'm not sure what the point of doing that is. 35-40MB/s is about as fast as you're going to get writing directly to the array. The ~100MB/s is the write speed limit of the disk I'm using for a cache disk. I don't have memory set to 4095MB and the dirtyable variable is set to 0. In other words I'm am getting the fastest write speeds that can be expected to both the array and the cache disk with the stock settings. Unless you're expecting the write speeds to slow down by changing the memory limit to 4095MB it seems like a pointless exercise to me.

 

Unraid itself is running inside a VM with 2 IBM M1015 controllers passed through. The VM has 8GB assigned to it. The system has 24GB of RAM total.

Link to comment

Let's do something simpler please, forget about earlier RCs for a moment. Let's focus on RC13 only.  Also, forget about the dirtyable thing for now, just set it to 0.  Lets do something very simple: Clock your writing speeds without mem=4095MB option, and then clock the same thing with the mem=4095MB option. Same files, same disk you write to, same RC13, same everything.  That will be interesting to compare.  And, for the test, do it with the same group of files with total size of more than 10GB please.

 

(BTW, you mentioned "VM" earlier. Is your unRaid running inside a VM, or did you mean that you're running VMs on unRaid?  If your unRaid is inside a VM, then how much is the total RAM on the host, and how much of it is dedicated to the virtualized unRaid?)

 

I'm not sure what the point of doing that is. 35-40MB/s is about as fast as you're going to get writing directly to the array. The ~100MB/s is the write speed limit of the disk I'm using for a cache disk. I don't have memory set to 4095MB and the dirtyable variable is set to 0. In other words I'm am getting the fastest write speeds that can be expected to both the array and the cache disk with the stock settings. Unless you're expecting the write speeds to slow down by changing the memory limit to 4095MB it seems like a pointless exercise to me.

 

Unraid itself is running inside a VM with 2 IBM M1015 controllers passed through. The VM has 8GB assigned to it. The system has 24GB of RAM total.

 

Well then, it looks like it's just hit and miss with different motherboards. My unRaid is not running in a VM, and for my mobo in RC13 the difference between with/without the 4gb option is more than double. Maybe your host os is doing something clever with the ram it passes to the VM.

 

 

It must be your board. Tom tested this same board and CPU with 16GB of RAM running on bare metal and the new kernel fixed the slow writes for him as well.

Link to comment

I don't want to be an ass or anything but trying to iron out a speed bug for one or two people is ridiculous.  If the chipset works with better write speeds now or even with the 4 GB limit then lets call this puppy final and move on.

 

Anyone who isn't happy (1 or 2) should be given the option of a refund and let's just move forward.  Sweet jesus I am running unRAID on a at least 4 year old setup with plenty of plugins and 4 GB of RAM and all is happy in the world.

 

Kryspy

Link to comment

I don't want to be an ass or anything but trying to iron out a speed bug for one or two people is ridiculous.  If the chipset works with better write speeds now or even with the 4 GB limit then lets call this puppy final and move on.

 

Anyone who isn't happy (1 or 2) should be given the option of a refund and let's just move forward.  Sweet jesus I am running unRAID on a at least 4 year old setup with plenty of plugins and 4 GB of RAM and all is happy in the world.

 

Kryspy

 

 

One of the big issues with getting it to work properly on the X9SCM, the same board I and tons of others on here have, is that Tom wanted to use this hardware in one of the new server configurations he is going to sell.

Link to comment

I don't want to be an ass or anything but trying to iron out a speed bug for one or two people is ridiculous.  If the chipset works with better write speeds now or even with the 4 GB limit then lets call this puppy final and move on.

 

Anyone who isn't happy (1 or 2) should be given the option of a refund and let's just move forward.  Sweet jesus I am running unRAID on a at least 4 year old setup with plenty of plugins and 4 GB of RAM and all is happy in the world.

 

Kryspy

AH but there it is, your happy! so lets move forward, that's not exactly fair is it. And it is not 1 or 2 people with those boards. If they are willing to help each other out and swap info and Tom's tweaking, etc. its for the greater good.

 

Your 4 year old setup fire's one day, you purchase new gear and you get 2mb transfer rates, you'll just want your money back, so now thats not fair to Tom.

I say you retract at the very least the refund part in your statement which you are not at liberty to offer and I will retract my whole post, ok.

 

I want to get AFP fixed but waiting at the moment for these other issues to be iron out.

Link to comment

It must be your board. Tom tested this same board and CPU with 16GB of RAM running on bare metal and the new kernel fixed the slow writes for him as well.

Well, my board is not some crappy cheapo board, it is a server grade Supermicro X7DBE with Xeon CPU.  In fact I have two servers with that same board, and I'm getting the same results on both servers.

You know the deal, he's on the receiving end of a fix, so someone else's problem is no longer a problem for him. It's human nature. Your going to have to wait on someone else willing to help in your requests and/or Tom to dive into yours now. Hang in there (I guess).

 

Link to comment

Hi Tom,

 

Back with RC-12 this issue cropped up. The mover does not seem to be deleting items on the cache drive after moving them.

 

I have sent a few emails to the official support email address and started a forum topic here:

 

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

 

I know you are swamped, but I noticed that you were active in this forum and thought I would try for a response here. This issue persists in RC-13 so it seems appropriate to bring up.

 

SysLog attached. Error codes at the end.

 

Thank you so much for the hard work,

 

Justin

syslog-2013-06-06.txt

Link to comment

You know the deal, he's on the receiving end of a fix, so someone else's problem is no longer a problem for him. It's human nature. Your going to have to wait on someone else willing to help in your requests and/or Tom to dive into yours now. Hang in there (I guess).

 

 

Well that's a little unfair to me. That wasn't the intention behind my comment at all. I'd like the issue to get resolved for him as well. I simply meant that it was indeed fixed on the X9SCM series boards, which is the claim Tom made in his original post.

 

 

First, the so-called "slow write" issue with X9SCM motherboards and similar.  This seems to be fixed in the linux 3.9.x kernel series.  Yes, earlier I said we'd stay on the latest "long term supported" kernel for a while.  Bottom line is that these kernels simply are not updated with all the bug fixes and support for newer h/w.  So back to keeping up-to-date with kernel guys.

Link to comment

How is this ever going to work going forward??  Is it going to be expected that "every" single motherboard will work and that if it doesn't it has to be fixed???  Going back the wiki was full of people who "tested" board and posted if they worked or not and that was the working hardware list and it was accepted that if it didn't work it didn't work.  I don't mean to sound harsh but if someone purchases an expensive motherboard do they think they deserve special treatment as it's not a cheapo board.  If someone takes the gamble and purchases a board that is untested it can be raised as a "this board doesn't work" but I do not think there should be an expectation that going forward it should be actively fixed esp if the board is used by 1 person.  I purchased a supermicro board that up until latest release had a known issue with slow writes under certain conditions I was hapopy with this as I was fully informed and made sure my deployment did not meet any of these criteria.  All of the boards I have purchased and used with unraid have been done so only after reading the forums the wiki and ensuring that there is at least some type of report about the board I am looking to purchase.

Link to comment

You know the deal, he's on the receiving end of a fix, so someone else's problem is no longer a problem for him. It's human nature. Your going to have to wait on someone else willing to help in your requests and/or Tom to dive into yours now. Hang in there (I guess).

 

 

Well that's a little unfair to me. That wasn't the intention behind my comment at all. I'd like the issue to get resolved for him as well. I simply meant that it was indeed fixed on the X9SCM series boards, which is the claim Tom made in his original post.

 

 

First, the so-called "slow write" issue with X9SCM motherboards and similar.  This seems to be fixed in the linux 3.9.x kernel series.  Yes, earlier I said we'd stay on the latest "long term supported" kernel for a while.  Bottom line is that these kernels simply are not updated with all the bug fixes and support for newer h/w.  So back to keeping up-to-date with kernel guys.

No disrespect toward you, it's  just it seem he was asking if you could help out with some tests and provide some #'s around those tests. And you are in your right to either not want too, or have the time, or now is not a good time to do so, etc. but it sounded more like a I don't see the point in any of those tests I am good. But for him it's very interesting how u and you MB went from very bad to just fine now. If you can help that's cool, if you can't that's alright too. He has an open wound and salt is not good right now. A beer and bandage would be great  ;)

Link to comment

if someone purchases an expensive motherboard do they think they deserve special treatment as it's not a cheapo board.

Yeah, yeah, yeah!  I also have a Suoermicro X8SIL-F with a Xeon in my test server. Guess what?  The same crap happens on that one too. So bug off. The X8SIL-F is a vey popular, and tested board, certainly not owned by only one person.  And if you can't support Supermicro boards, which are the most reliable server boards ever, then what on earth are we really talking about?

 

A very popular and tested board working completely fine with no issues in unraid no reports of issues used by limetech in their own builds that they sell great well then you have no issues do you.  So then you think the product should work with all 50+ boards supermicro sell??

Link to comment

if someone purchases an expensive motherboard do they think they deserve special treatment as it's not a cheapo board.

Yeah, yeah, yeah!  I also have a Suoermicro X8SIL-F with a Xeon in my test server. Guess what?  The same crap happens on that one too. So bug off. The X8SIL-F is a vey popular, and tested board, certainly not owned by only one person.  And if you can't support Supermicro boards, which are the most reliable server boards ever, then what on earth are we really talking about?

I have the SM X8SI6-F I had many problem as I went hardcore for LSI controller support in early beta's many people helped with that including pushing Tom (I don't mean that in a bad way) and published Some stuff around that so other had choices with controllers. Anyways I had very bad issue with that board and massive oops errors when spinup/down, array shutdowns and reboots. Tom tried to help me one on one but it was never resolved. So to the other poster he does what he can but no one stopped anything for me and my board... So i used VMware in the work place and decide to make an attempt to virtualized unRAID this was way before johns posts. And it resolved my issues for that board from crashing. So then is was just a wait for Tom working out sas controller support and unRAID spinup/down tweaking. That came around slowly. Then after beta12a my speeds went down with each release. They are ok with rc12a but I miss the previous speeds.

 

So if you want to take this to another thread with our SM family boards. I can share my exact setup and I can test anything you want, as long as you guide me, I am no Linux guru, but learned enought to get around for sure. And not tonight I'm in bed  ;D

Link to comment

if someone purchases an expensive motherboard do they think they deserve special treatment as it's not a cheapo board.

Yeah, yeah, yeah!  I also have a Suoermicro X8SIL-F with a Xeon in my test server. Guess what?  The same crap happens on that one too. So bug off. The X8SIL-F is a vey popular, and tested board, certainly not owned by only one person.  And if you can't support Supermicro boards, which are the most reliable server boards ever, then what on earth are we really talking about?

 

Exactly that

A very popular and tested board working completely fine with no issues in unraid no reports of issues used by limetech in their own builds that they sell great well then you have no issues do you.  So then you think the product should work with all 50+ boards supermicro sell??

 

Yes, all Supermicro boards that I have -- the H8DAE, the X7DBE, and the X8SIL-F -- they have absolutely no issues whatsoever with unRaid 4.7.  So what's your point?

Link to comment

I think this is all going a little sideways. Suffice it to say that there seems to still be an issue with at least one of these boards. I also have one, but I'm not testing RC13 on it due to the runaway sync issue. However, there needs to be a little bit of patience here, because Tom did introduce a new kernel in this release. That clearly has added a few problems and fixed some others. Since he's already shipping 5.0 final with his new server that uses this exact board, it does indicate that at least in his testing, on his systems, this issue has been rectified. That's certainly not to say that he will ignore your issue going forward.

Link to comment

I think this is all going a little sideways. Suffice it to say that there seems to still be an issue with at least one of these boards. I also have one, but I'm not testing RC13 on it due to the runaway sync issue. However, there needs to be a little bit of patience here, because Tom did introduce a new kernel in this release. That clearly has added a few problems and fixed some others. Since he's already shipping 5.0 final with his new server that uses this exact board, it does indicate that at least in his testing, on his systems, this issue has been rectified. That's certainly not to say that he will ignore your issue going forward.

Thank you for your voice of reason.

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.