limetech Posted June 15, 2013 Share Posted June 15, 2013 Download | Release Notes Patch applied to latest linux kernel to solve "continuous writes as a result of sync" and "possible crash when Stopping array" bugs. So now back to the latest and greatest No more workaround to reduce memory either, should just work. Link to comment
dirtysanchez Posted June 15, 2013 Share Posted June 15, 2013 Server is currently in use but will load this up later tonight. Thank you Tom for all the hard work!! Link to comment
PeterB Posted June 15, 2013 Share Posted June 15, 2013 Great news. Have the Linux kernel team been active in solving these issues? If so, good to hear. Will wait to load the new version tomorrow, after I see whether apcupsd log rotation issue is provoked at 3:40. Link to comment
limetech Posted June 15, 2013 Author Share Posted June 15, 2013 Great news. Have the Linux kernel team been active in solving these issues? If so, good to hear. Will wait to load the new version tomorrow, after I see whether apcupsd log rotation issue is provoked at 3:40. In my experience the people who work on linux are extremely helpful and intelligent. If you can detail exactly how to make a problem repeatable they figure it out very quickly. Link to comment
mejutty Posted June 15, 2013 Share Posted June 15, 2013 Just loaded up my test esxi install all good so far. Link to comment
nars Posted June 15, 2013 Share Posted June 15, 2013 Loading it on my test system, thank you and hope it solves all problems Link to comment
garycase Posted June 15, 2013 Share Posted June 15, 2013 Good news. I'm running a parity check right now (to test another issue), but when it completes, I'll load this up & give it a whirl. Link to comment
nars Posted June 15, 2013 Share Posted June 15, 2013 or rc16 hehe hopefully not btw Tom, when possible.. if you could please give a quick look and comment something about this: http://lime-technology.com/forum/index.php?topic=27893.0 thanks. Link to comment
calypsocowboy Posted June 15, 2013 Share Posted June 15, 2013 System booted, no USB not found errors, configuration valid, array started and parity is running right now. Will check again in the morning. Tom, thanks again for all your hard work. I know we don't say it enough. -Josh Link to comment
garycase Posted June 15, 2013 Share Posted June 15, 2013 Loaded RC15, rebooted & all was well. Shut down to confirm no shutdown issues. Rebooted and copied a couple large files to confirm no performance issues (definitely none -- got over 120MB/s copy speed ... clearly maxing my Gb Ethernet. Disconnected power from UPS to confirm APC UPS package didn't have any shutdown issues ... shutdown went as planned, and system is now back up. Finally, cleared all stats and started a parity check => will post results tomorrow, but don't anticipate any problems. Nicely done Tom -- very quick turnaround on getting all the issues that RC13 introduced resolved and getting everything ready for a "final" release of v5 Hopefully that will only be a few days away -- but I'm sure if there are hidden bugs that this community will quickly find them for you Link to comment
Ice_Black Posted June 15, 2013 Share Posted June 15, 2013 Thanks Tom! Upgraded to RC15 and going smooooooth so far. Doing Parity-Check right now. Link to comment
mejutty Posted June 15, 2013 Share Posted June 15, 2013 One thing I have just noticed and can confirm from the above is there does appear to be way more reads on the parity disk during a parity check than on my RC10 machine. My RC10 machine reads on the data disks to the parity disk are 1 to 1. I just kicked of a parity check on my RC10 machine and then cleared statists and across all 9 disks (8 data 1 parity) the reads counters are identical. On my RC15 machine reads on the parity disk is reading 175% of the reads that the data disk is. RC10 Disk 1 WDC_WD30EZRX-00MMMB0_WD-WCAWZ1155791 (sde) 2930266532 22 °C 3 TB 2.67 TB 335 GB 48,838 0 0 Disk 2 WDC_WD30EZRX-00MMMB0_WD-WMAWZ0431836 (sdb) 2930266532 22 °C 3 TB 2.71 TB 293 GB 48,838 0 0 Disk 3 Hitachi_HDS5C3030ALA630_MJ1323YNG1GM6C (sdd) 2930266532 24 °C 3 TB 2.66 TB 339 GB 48,838 0 0 Disk 4 Hitachi_HDS5C3030ALA630_MJ1323YNG1BZGC (sda) 2930266532 24 °C 3 TB 2.69 TB 307 GB 48,838 0 0 Disk 5 Hitachi_HDS5C3030ALA630_MJ1313YNG2GKNC (sdf) 2930266532 25 °C 3 TB 2.23 TB 775 GB 48,838 0 0 Disk 6 Hitachi_HDS5C3030ALA630_MJ1321YNG0E2EA (sdc) 2930266532 24 °C 3 TB 2.72 TB 280 GB 48,838 0 0 Disk 7 Hitachi_HDS724040ALE640_PK1331PAGGXLLV (sdj) 3907018532 26 °C 4 TB 2.90 TB 1.10 TB 48,835 0 0 Disk 8 ST3000DM001-9YN166_W1F004TP (sdh) 2930266532 23 °C 3 TB 1.90 TB 1.10 TB 48,838 0 0 RC15 parity WDC_WD6400AAKS-65A7B0_WD-WMASY2624921 (sdb) 625131832 38°C 640.13 GB - 31427 0 0 disk1 WDC_WD5000AAKS-00A7B0_WD-WMASY0626391 (sdc) 488385496 36°C 500.11 GB 446.79 GB 17890 0 0 I am guessing could result in slower parity checks if it is doing more reads than it requires. Can't compare like for like hardware atm. Just read through the other thread looks like change happened sometime after RC10 that that sound about correct?? Link to comment
Wody Posted June 15, 2013 Share Posted June 15, 2013 I had a slight issue with the latest versions, because normally I update the bzroot and bzimage files on the unraid server while it is on and running. That didn't work because suddenly the disks and usb-device didn't show up, due to some extra settings in the share.cfg file. Adding those to my generated share.cfg fixed that, so now I can do that again, but it isn't specified in the upgrade-notes, I assume that will be added? Link to comment
Ice_Black Posted June 15, 2013 Share Posted June 15, 2013 I had a slight issue with the latest versions, because normally I update the bzroot and bzimage files on the unraid server while it is on and running. I think this is not normal. You suppose to shutdown, update and restart. This is not unRAID issue. Link to comment
Harpz Posted June 15, 2013 Share Posted June 15, 2013 I just copied the bzroot and bzimage via network to flash and rebooted, all appears to be fine, running parity check now, seems faster but we'll see. Link to comment
Guest Barzija Posted June 15, 2013 Share Posted June 15, 2013 I had a slight issue with the latest versions, because normally I update the bzroot and bzimage files on the unraid server while it is on and running. I think this is not normal. You suppose to shutdown, update and restart. Not really. If he has normal read/write access to the flash disk, he can update the two files before restarting. They are not used by the system at run time. Link to comment
peter_sm Posted June 15, 2013 Share Posted June 15, 2013 I'm happy with RC15, but is the cache pool implemented? I have looked around but cant find any related configuration settings for this. Thanks Tom for a GREAT work you do on this, now I looking forward to use the 64-bit release. //Peter Link to comment
garycase Posted June 15, 2013 Share Posted June 15, 2013 One thing I have just noticed and can confirm from the above is there does appear to be way more reads on the parity disk during a parity check than on my RC10 machine. My RC10 machine reads on the data disks to the parity disk are 1 to 1. There aren't more reads ... they're just being reported differently. I believe the difference is that you're seeing the number of physical I/O's done by the disk driver in RC15, whereas you were previously seeing the number of logical read requests send to the disk driver. Since the disk driver optimizes access, these numbers are different. A more interesting question is WHY you were seeing the identical-across-disks numbers with RC10 !! looks like change happened sometime after RC10 that that sound about correct?? No. Actually the change in the method of reporting reads happened well before v4.7 My v4.7 machine shows widely varying numbers of reads between different disks of the same size during parity checks ... and there's no apparent correlation between the numbers and the size of the disks. My v5 machine has always show widely varying numbers as well; and in that case all 6 disks are identical (3TB WD Reds). For example, a parity check I completed last night with RC14 had 21,127,908 reads for the parity drive; with the data drives varying between 20,635,159 and 41,340,143 reads. Interestingly, I had just decided to ask a question to see if anyone knew the reasons behind these disparities, and Tom provided a good answer that confirmed what I had assumed was happening accounts for it -- but he indicated it's a change he made "... some time way-back, pre 4.7 ..." Also interesting, WeeboTech indicated in the same thread that his numbers do NOT vary !! So SOMETHING is different on SOME setups that results in the numbers matching; whereas they most likely should be different, as I've seen for years; and as Tom confirmed in his reply. You may want to read through the question I asked on this: http://lime-technology.com/forum/index.php?topic=27893.0 Link to comment
dalben Posted June 15, 2013 Share Posted June 15, 2013 Installed RC15. No problems that I can see with it coming up and launching a multitude of plugins and packages. Link to comment
johnodon Posted June 15, 2013 Share Posted June 15, 2013 Updated to RC15. Stopped the array and rebooted 3 times without issue. NFS shares accessible on my OpenELEC boxes. Running parity check now... Total size: 2 TB Current position: 101.68 GB (5%) Estimated speed: 99.96 MB/sec Estimated finish: 317 minutes Sync errors corrected: 0 John Link to comment
doorunrun Posted June 15, 2013 Share Posted June 15, 2013 Tom, thanks for the early Father's Day gift! I'm running this RC with my usual plugins after initially testing it as shipped. I have Barzija's Keeplogs running as a precaution. The system seems to boot very quickly. Best wishes for a quiet and relaxing weekend! Link to comment
navi Posted June 15, 2013 Share Posted June 15, 2013 I just want to confirm what it says in the release notes. I am currently running rc12a with 2GB of memory. To upgrade to rc15 I should copy bzimage, bzroot and syslinux.cfg to the flash drive? There is no need for editing syslinux.cfg with this release? Thanks. Link to comment
garycase Posted June 15, 2013 Share Posted June 15, 2013 I just want to confirm what it says in the release notes. I am currently running rc12a with 2GB of memory. To upgrade to rc15 I should copy bzimage, bzroot and syslinux.cfg to the flash drive? There is no need for editing syslinux.cfg with this release? Thanks. That's correct -- the syslinux.cfg distributed with RC15 does not have the "4GB" option in it. This was the option included in the previous release that I had suggested you should not use (as it caused problems for many who didn't have 4GB in their systems). So all you need to do is copy bizimage, bizroot, and syslinux.cfg to the flash drive (you can do this while the system is running); and then simply reboot the system. Link to comment
navi Posted June 15, 2013 Share Posted June 15, 2013 I just want to confirm what it says in the release notes. I am currently running rc12a with 2GB of memory. To upgrade to rc15 I should copy bzimage, bzroot and syslinux.cfg to the flash drive? There is no need for editing syslinux.cfg with this release? Thanks. That's correct -- the syslinux.cfg distributed with RC15 does not have the "4GB" option in it. This was the option included in the previous release that I had suggested you should not use (as it caused problems for many who didn't have 4GB in their systems). So all you need to do is copy bizimage, bizroot, and syslinux.cfg to the flash drive (you can do this while the system is running); and then simply reboot the system. Thanks for the clarification. I just wanted to be sure. Link to comment
Dephcon Posted June 15, 2013 Share Posted June 15, 2013 No issues so far with rc15 here. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.