unRAID Server Release 5.0-rc15 Available


Recommended Posts

  • Replies 142
  • Created
  • Last Reply

Top Posters In This Topic

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

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  8)

 

Link to comment

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

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
Guest Barzija

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

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

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

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

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

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

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

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
Guest
This topic is now closed to further replies.