unRAID Server Release 5.0-rc13 Available


Recommended Posts

Download | Release Notes

 

There are two main issues this addresses.

 

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.

 

Speaking of new kernel... I also ditched the Realtek-supplied r8168/9 drivers again, and went back to the kernel-supplied r8169 driver.  Why did I do this?  Just to tick people off?  Absolutely not.  If testing reveals still problems I will generate another -rc13a patch release and put them back (but it will take some work).  Bottom line here is that I just don't trust Realtek to keep up with kernel development - case in point: they don't compile as-is against 3.9.x source tree.

 

Second main issue this addresses is NFS stale file handles.  If you want to use NFS with user shares, then you need to do some set up explained here:

http://lime-technology.com/wiki/index.php?title=Plugin/webGui/NFS

 

There is a better fix for this which will go into a future release.

 

A couple other interesting changes:

 

- I was having problems with some hard drives reporting errors, but not resulting in being reported to the driver.  That is, if the low-level 'libata' layer can recover from certain link errors, it does so and doesn't propagate status up.  You just get a bunch of error messages that identify the disks as "ATA1" or "ATA12", etc.  After thoroughly researching and looking at code I have concluded there is no fool-proof way to correlate these identifiers with the normal identifiers used for disks (ie, sda, sdb, etc).  So I went and modified the code that displays this config information to output both the hard drive model and serial number string.  So now you can go and search for a drive model/serial number in syslog and find which "ATA" identifier was used (finally).  The code doesn't do anything with this at present but tool now exists to report these link errors in the future.  The file that I modified is on the flash at /usr/src/linux/drivers/ata/libata-core.c.

 

- Increased the max number of file handles, and max inotify watches since this may be necessary to support some plugins.

 

Again, barring any show-stopper type problems, this release will become 5.0 "final" in a matter of days.  All that 's left to do is finish the documentation.

 

One more note: I will create a page on the wiki that details the "roadmap" I have for my own use.  Probably will get to that tomorrow.

 

Thank you to everyone who uses and supports unRaid, and believe me, I very much appreciate all comments whether they are good, bad, or ugly.

 

 

Link to comment
  • Replies 341
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Good work -- glad you have all the key issue put to bed.   

 

I DO have one question for you:  In your opinion is this a more stable release than 4.7 ??    I ... and many others ... have clearly been VERY satisfied with the rock-solid performance of 4.7, and quite frankly the only reason my 2nd server is a v5 system is that I wanted to use > 2TB drives.    My older system has plenty of space with the 2TB drives, and won't likely need an upgrade for larger drives for at least a couple years.    Would you recommend upgrading that one to v5 ... or would you suggest just following the old tried and true "leave well enough alone" ???

 

Link to comment

Thanks for the continued efforts Tom, much appreciated!

 

I finally jumped onto these RCs with 12a (using stock unRAID HW) - all running smoothly :)

 

 

BTW - are the upgrade instructions in the Release Notes for upgrading FROM 5.0-rc12/12a the same as the section currently entitled "5.0-rc9 through 5.0-rc11"???

Link to comment

Just updated my vmdk and fired it up. So far so good. I'm testing the new feature to prevent stale file handles with NFS. Also changing vm.highmem_is_dirtyable back to 0, as that had solved my slow write issue, to see if the slow write issue is gone.

Link to comment

Not sure what good it'll do because i've reported the issue about a dozen times, and others have posted about it elsewhere... but here it goes again at some hope of official confirmation. Two servers, both in signature, same issues, same hardware.

 

unRAID RCs (Including RC13) results in roughly:

Current position: 1.93 GB (0.1 %)

Estimated speed: 46.4 MB/sec

 

unRAID Beta11 and earlier results in roughly:

Current position: 1.87 GB (0.1 %)

Estimated speed: 121.8 MB/sec

 

Letting them go to 10% results in no speed difference, it's about 6 hour versus 18 hour parity checks. I have downgraded many times to confirm it's not a fluke. Something changed and messed up SAS2LP cards. I *believe* you need more than 1 SAS2LP card to be affected by the issues.

Link to comment

 

Not sure what good it'll do because i've reported the issue about a dozen times, and others have posted about it elsewhere... but here it goes again at some hope of official confirmation. Two servers, both in signature, same issues, same hardware.

 

unRAID RCs (Including RC13) results in roughly:

Current position: 1.93 GB (0.1 %)

Estimated speed: 46.4 MB/sec

 

unRAID Beta11 and earlier results in roughly:

Current position: 1.87 GB (0.1 %)

Estimated speed: 121.8 MB/sec

 

Letting them go to 10% results in no speed difference, it's about 6 hour versus 18 hour parity checks. I have downgraded many times to confirm it's not a fluke. Something changed and messed up SAS2LP cards. I *believe* you need more than 1 SAS2LP card to be affected by the issues.

 

 

Have you tried adjusting the tunables as Pauven suggested in his thread. He has a RocketRaid card which uses a multiple of the same chipset as the SAS2LP and he has had some great results adjusting tunables.

Link to comment

 

Not sure what good it'll do because i've reported the issue about a dozen times, and others have posted about it elsewhere... but here it goes again at some hope of official confirmation. Two servers, both in signature, same issues, same hardware.

 

unRAID RCs (Including RC13) results in roughly:

Current position: 1.93 GB (0.1 %)

Estimated speed: 46.4 MB/sec

 

unRAID Beta11 and earlier results in roughly:

Current position: 1.87 GB (0.1 %)

Estimated speed: 121.8 MB/sec

 

Letting them go to 10% results in no speed difference, it's about 6 hour versus 18 hour parity checks. I have downgraded many times to confirm it's not a fluke. Something changed and messed up SAS2LP cards. I *believe* you need more than 1 SAS2LP card to be affected by the issues.

 

 

Have you tried adjusting the tunables as Pauven suggested in his thread. He has a RocketRaid card which uses a multiple of the same chipset as the SAS2LP and he has had some great results adjusting tunables.

 

I did in the past, can you link his post so I can try using his exact variables?

 

EDIT: Found it, I tried his value of 896 and it seemed to take one server to about 70.9MB/s and the other to about 101.2MB/s. 1024 and 1280 looks to be even a little faster yet, especially on my server with more drives.  This is roughly a 2x improvement! The slower server has about 3 more drives in it and they are slower, so it's expected. Thanks for the suggestion. :)

 

Highly suggest any users with SAS2LP cards set md_sync_window to 896, 1024 or 1280 and choose whatever value gives them the fastest parity checks. For me, it looks like it is 1280.

Link to comment

...This seems to be fixed in the linux 3.9.x kernel series...

 

I notice you used 3.9.3.  Just curious if there's a particular reason not to use 3.9.4 (24-May-2013)

 

If I had to guess, it's because he had already settled on 3.9.3 when he was trying to finalize things for this RC. 3.9.4 would have required a whole new battery of testing.

Link to comment

To my surprise Realtek NIC booted just fine :)

 

One minor hiccup - 2.5" hard drive which is mounted via '/boot/config/go' script changed the address from /dev/sdb to /dev/sdc, any idea why would this happen? Just curious, it's not really an issue for me.

 

Link to comment

To my surprise Realtek NIC booted just fine :)

 

One minor hiccup - 2.5" hard drive which is mounted via '/boot/config/go' script changed the address from /dev/sdb to /dev/sdc, any idea why would this happen? Just curious, it's not really an issue for me.

 

 

Those assignments are random and can change at any time during boot up.

Link to comment

 

I loaded RC13, rebooted.

 

Getting some mem errors during the first stages of boot in the syslog. Anyone else getting them?  Only went from RC12 to RC13.

 

Tower kernel:  [mem 0x00000000-0x000fffff] page 4k (Errors)

 

sys log attached.

 

And you've reloaded RC12 and the memory errors go away?

Link to comment

And you've reloaded RC12 and the memory errors go away?

Just waiting on a reboot.  I just wanted to know if it was just me! ;)

 

Update:

 

Just rebooted and no mem errors at all.  Sys log for 12a is attached.  Any one have any ideas what's causing it?  I didn't disable my plugins BUT the mem errors are very early on, before they even kick in and I haven't had any issues with upgrades since I went from 4.7 to RC10. 11 and 12.

syslog-2013-06-04_1.txt

Link to comment
Second main issue this addresses is NFS stale file handles.  If you want to use NFS with user shares, then you need to do some set up explained here:

http://lime-technology.com/wiki/index.php?title=Plugin/webGui/NFS

 

There is a better fix for this which will go into a future release.

 

I guess that I need to wait for the 'better' fix, then!  In the meantime I will revert to RC10.

 

I ran one mkvmerge from my 'Torrent' user share to my 'Movies' user share then went to open the 'Movies' share in Nautilus - this resulted in a 'stale nfs file handle' report.

 

I still don't understand why this problem was absent between rc4 and rc10, but returned in rc11.

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.