limetech Posted June 4, 2013 Share Posted June 4, 2013 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. Quote Link to comment
Rajahal Posted June 4, 2013 Share Posted June 4, 2013 Thanks Tom, great work! Looking forward to the 'stable' at the end of the tunnel! Quote Link to comment
mrow Posted June 4, 2013 Share Posted June 4, 2013 Can't wait to load it up and try it out! Thanks! Quote Link to comment
cj0r Posted June 4, 2013 Share Posted June 4, 2013 Thanks Tom, great work! Looking forward to the 'stable' at the end of the tunnel! I see what you did there Excellent news Tom, you can always expect my support. Quote Link to comment
garycase Posted June 4, 2013 Share Posted June 4, 2013 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" Quote Link to comment
Joe L. Posted June 4, 2013 Share Posted June 4, 2013 It booted! (on the C2SEE SuperMicro MB... without needing an additional Realtk driver version 13a) No other report so far, but it is important first step. Joe L. Quote Link to comment
ClunkClunk Posted June 4, 2013 Share Posted June 4, 2013 - Increased the max number of file handles, and max inotify watches since this may be necessary to support some plugins. Is this to address the Transport Endpoint not connected errors that Plex users were seeing? Quote Link to comment
optiman Posted June 4, 2013 Share Posted June 4, 2013 It booted! (on the C2SEE SuperMicro MB... without needing an additional Realtk driver version 13a) No other report so far, but it is important first step. Joe L. Thanks Joe! That's what I'm running, can't wait to load it! Quote Link to comment
magic144 Posted June 4, 2013 Share Posted June 4, 2013 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" Quote Link to comment
calypsocowboy Posted June 4, 2013 Share Posted June 4, 2013 I'm up and running as well, this solved the issues I was having with 11 and 12a with not being able to come up. I'm still seeing some udevd worker failed errors but it's running which was more than before. Running parity now. -Josh Quote Link to comment
optiman Posted June 4, 2013 Share Posted June 4, 2013 confirmed - loaded just fine, no need for extra nic drivers- all seems good. Quote Link to comment
mrow Posted June 4, 2013 Share Posted June 4, 2013 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. Quote Link to comment
tyrindor Posted June 4, 2013 Share Posted June 4, 2013 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. Quote Link to comment
mrow Posted June 4, 2013 Share Posted June 4, 2013 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. Quote Link to comment
tyrindor Posted June 4, 2013 Share Posted June 4, 2013 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. Quote Link to comment
mrow Posted June 4, 2013 Share Posted June 4, 2013 I did, can you link his thread so I can try using his exact variables? Looks like the first post on page 12 has what he found were the best settings. http://lime-technology.com/forum/index.php?topic=27460.165 Quote Link to comment
mrow Posted June 4, 2013 Share Posted June 4, 2013 ...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. Quote Link to comment
garycase Posted June 4, 2013 Share Posted June 4, 2013 Running fine on my SuperMicro X7SPA-H-D525-O Atom. Going to run a parity check overnight just to see if there's any change in parity check speed. Quote Link to comment
joyless Posted June 4, 2013 Share Posted June 4, 2013 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. Quote Link to comment
mrow Posted June 4, 2013 Share Posted June 4, 2013 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. Quote Link to comment
GrantR Posted June 4, 2013 Share Posted June 4, 2013 Thats fantastic, looking forward to the final release. I take it that ipv6 support is not going to make 5 final if no other major additions are to come? I saw it in IssueList for version 5.x Quote Link to comment
Lacehim Posted June 4, 2013 Share Posted June 4, 2013 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. syslog-2013-06-04.txt Quote Link to comment
mrow Posted June 4, 2013 Share Posted June 4, 2013 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? Quote Link to comment
Lacehim Posted June 4, 2013 Share Posted June 4, 2013 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 Quote Link to comment
PeterB Posted June 4, 2013 Share Posted June 4, 2013 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. Quote Link to comment
Recommended Posts
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.