limetech Posted August 26, 2011 Share Posted August 26, 2011 Download | Release Notes Note: if you see a crash or some other issue, please include a system log. Edit: let me rephrase the above: if I need to see the system log in order to diagnose the issue, and you have not already attached your system log, I am not going to ask you to do it, I am just going to delete your post. Quote Link to comment
Thornwood Posted August 26, 2011 Share Posted August 26, 2011 Thank you for your hard work I will test today. Quote Link to comment
cyrnel Posted August 26, 2011 Share Posted August 26, 2011 My backup system came up with the array automatically started. All disks/filesystems look fine so no harm but thought it worth mentioning. Syslog attached. Edit: This was b11 to b12. Edit2: Yes, autostart was enabled. Didn't think I'd set that but I may be getting different tests systems mixed up. Disregard. syslog-b12boot.txt Quote Link to comment
gfjardim Posted August 26, 2011 Share Posted August 26, 2011 So far these are my findings: a) The array started automatically. I though that when the system got upgraded, the array would be stopped at the first boot; b) Mounting, umounting and rebooting the system didn't led to any crash or kernel oops; c) Just started a parity check, but the speed seems compatible with older betas. So far, so good. Will update the post when the parity check finishes. Congratulations, Tom, for the awesome work porting unRAID to kernel 3.0.3! PS: I suggest to those people with Realtek 8111E NICs to test this one, but seems that the driver is the r8169. Quote Link to comment
limetech Posted August 26, 2011 Author Share Posted August 26, 2011 My backup system came up with the array automatically started. All disks/filesystems look fine so no harm but thought it worth mentioning. Syslog attached. Edit: This was b11 to b12. How do you have "Settings/Disk settings/Enable auto start" (Yes or No)? I tried both states and it seems to work. Quote Link to comment
limetech Posted August 26, 2011 Author Share Posted August 26, 2011 So far these are my findings: a) The array started automatically. I though that when the system got upgraded, the array would be stopped at the first boot; See my previous post. Unless "Enable auto start" is set to No it will start up regardless of upgrading. b) Mounting, umounting and rebooting the system didn't led to any crash or kernel oops; c) Just started a parity check, but the speed seems compatible with older betas. What rate are you getting after say running for 5 min? So far, so good. Will update the post when the parity check finishes. Congratulations, Tom, for the awesome work porting unRAID to kernel 3.0.3! PS: I suggest to those people with Realtek 8111E NICs to test this one, but seems that the driver is the r8169. Yes, driver is r8169. Quote Link to comment
gfjardim Posted August 26, 2011 Share Posted August 26, 2011 b) Mounting, umounting and rebooting the system didn't led to any crash or kernel oops; c) Just started a parity check, but the speed seems compatible with older betas. What rate are you getting after say running for 5 min? The current position is 12% of 2TB and I'm getting 82MB/s, because I have some old WD10EACS drives in my array. This speed is expected and compatible with older measures. Quote Link to comment
BRiT Posted August 26, 2011 Share Posted August 26, 2011 Just upgraded my Slackware 64 13.37 full distro to unRAID 5.0 beta 12 and the Linux 3.0.3 kernel. So far so good for me too. The parity check speed seems more comparable to the 2.6.37.x series. Parity check started 10 minutes ago on a 6-drive (5 data + parity drive mix of WD and Seagate Greens) 2TB array, it's at 62.50 GB (3%), with estimated speed of 100.51 MB/sec and finish time of 321 minutes. Quote Link to comment
gfjardim Posted August 26, 2011 Share Posted August 26, 2011 driver: incorporate "explicit block device plugging" (http://lwn.net/Articles/438256/) This was the catch that avoided the kernel upgrade before, Tom? Quote Link to comment
speeding_ant Posted August 27, 2011 Share Posted August 27, 2011 So far so good. Speed of copy seems a bit quicker, server seems more responsive. Been having issues with interface resets since I built my new server. Isn't on a specific port. Happens with two setups, exact same motherboard. My motherboard is a Gigabyte GA-870A-UD3. Unsure if it's just BIOS setup (everything set to AHCI). Syslog attached. syslog.txt Quote Link to comment
BRiT Posted August 27, 2011 Share Posted August 27, 2011 Parity check started 10 minutes ago on a 6-drive (5 data + parity drive mix of WD and Seagate Greens) 2TB array, it's at 62.50 GB (3%), with estimated speed of 100.51 MB/sec and finish time of 321 minutes. Parity check started 245 minutes ago on a 6-drive (5 data + parity drive mix of WD and Seagate Greens) 2TB array, it's at 1.31 TB (66%), with estimated speed of 73.8 MB/sec and finish time of 158 minutes. Quote Link to comment
Johnm Posted August 27, 2011 Share Posted August 27, 2011 parity check going strong. 8 Hitachi 3TB drives running unRAID in a hypervisor. it was at 116MB/s 20% in. It is about 103MB/s at 60% I am still using the array the whole time. watching blurays and uploading more to the array. Friday night movies in the backyard with the projector... Quote Link to comment
disco Posted August 27, 2011 Share Posted August 27, 2011 Yes! Parity sync on beta11 was going at around 30MB/sec and then gradually slowed down to 2MB/sec after about 50%. Now I'm 10% in and at 85.79MB/sec. Awesome! Quote Link to comment
pras1011 Posted August 27, 2011 Share Posted August 27, 2011 I have installed beta 12 and I get this: Aug 27 12:20:29 Unraid kernel: ata9: sas eh calling libata port error handler I have attached my syslog as this error is everywhere. unraid.txt Quote Link to comment
Yorgo Posted August 27, 2011 Share Posted August 27, 2011 Still having the same NIC issues. Maybe it's time to bite the bullet and just buy a new card . . . http://lime-technology.com/forum/index.php?topic=14158.msg134868#msg134868 Y Quote Link to comment
gfjardim Posted August 27, 2011 Share Posted August 27, 2011 Ok, the parity finished and took 7h48m to complete, almost the same time it took previously. Regarding the Realtek 8111E, since the new driver got merged I saw no improvement into the changelogs that could resolve this issue. This is a Linux kernel bug, not just an unRAID bug. Quote Link to comment
aht961 Posted August 27, 2011 Share Posted August 27, 2011 The bug concerning the connection to the SMB shares via sidebar in Lion is sorted out with this release, so there is no need to hack the port numbers in conf files. Now, both SMB and AFP shares are usable via the sidebar. Thank you. Quote Link to comment
BRiT Posted August 27, 2011 Share Posted August 27, 2011 Parity check started 10 minutes ago on a 6-drive (5 data + parity drive mix of WD and Seagate Greens) 2TB array, it's at 62.50 GB (3%), with estimated speed of 100.51 MB/sec and finish time of 321 minutes. Parity check started 245 minutes ago on a 6-drive (5 data + parity drive mix of WD and Seagate Greens) 2TB array, it's at 1.31 TB (66%), with estimated speed of 73.8 MB/sec and finish time of 158 minutes. Parity check on a 6-drive (5 data + parity drive mix of WD and Seagate Greens) 2TB array finished in 26128 seconds, with an actual average speed of 73 MB/sec. This is roughly in line with previous parity check speeds. Others were more along the 75 MB/s, but the array was being used more this time around than the previous parity checks, so that might explain the overall 2 MB/s difference. Quote Link to comment
crazytony Posted August 27, 2011 Share Posted August 27, 2011 Parity ran ok; it ran a little more quickly than usual (85MB/sec) but I have to revert back to the b9 version because the NFS issue in 11 and 12. Attached is the syslog. I removed all the md5deep files and the problem still continues. It is only happening on files written to my new disk. I originally thought it was permissions but I fixed all of those issues. If I downgrade to b9 this whole problem goes away. The only thing that is telling is the syslog from the machine using NFS (NOT the unraid machine). Aug 27 23:19:20 frontmedia kernel: [125865.176644] NFS: server 192.168.1.4 error: fileid changed Aug 27 23:19:20 frontmedia kernel: [125865.176649] fsid 0:16: expected fileid 0x80000046, got 0xffffffff80000046 Aug 27 23:37:24 frontmedia kernel: [126949.324965] NFS: server 192.168.1.4 error: fileid changed Aug 27 23:37:24 frontmedia kernel: [126949.324970] fsid 0:17: expected fileid 0x80000049, got 0xffffffff80000049 syslog.txt Quote Link to comment
Auggie Posted August 27, 2011 Share Posted August 27, 2011 With any "recent" 3TB capable beta's, has anyone: 1) Upgraded their parity drive to a 3TB and successfully built parity onto it? 2) Subsequently upgraded a data disk to a 3TB and successfully rebuilt data onto it? In both cases, I'm upgrading from 2TB drives. Quote Link to comment
limetech Posted August 27, 2011 Author Share Posted August 27, 2011 Parity ran ok; it ran a little more quickly than usual (85MB/sec) but I have to revert back to the b9 version because the NFS issue in 11 and 12. Attached is the syslog. I removed all the md5deep files and the problem still continues. It is only happening on files written to my new disk. I originally thought it was permissions but I fixed all of those issues. If I downgrade to b9 this whole problem goes away. The only thing that is telling is the syslog from the machine using NFS (NOT the unraid machine). Aug 27 23:19:20 frontmedia kernel: [125865.176644] NFS: server 192.168.1.4 error: fileid changed Aug 27 23:19:20 frontmedia kernel: [125865.176649] fsid 0:16: expected fileid 0x80000046, got 0xffffffff80000046 Aug 27 23:37:24 frontmedia kernel: [126949.324965] NFS: server 192.168.1.4 error: fileid changed Aug 27 23:37:24 frontmedia kernel: [126949.324970] fsid 0:17: expected fileid 0x80000049, got 0xffffffff80000049 From the machine accessing the unRaid server, can you try accessing files on the unRaid server via both a "user share" and a direct disk share? This will help me determine where in the code to look for this issue. In other words I want to know if it happens: a) when accessing files via user share on unRaid side b) when accessing files via disk share on unRaid side c) or both Quote Link to comment
limetech Posted August 27, 2011 Author Share Posted August 27, 2011 Still having the same NIC issues. Maybe it's time to bite the bullet and just buy a new card . . . http://lime-technology.com/forum/index.php?topic=14158.msg134868#msg134868 Y I might know what this issue is Please download the attached file and put into root of your flash share (same directory where bzimage/bzroot, etc., is located). Then from command line type this: sysctl -p /boot/sysctl.conf Now see if studdering still happens. sysctl.conf Quote Link to comment
limetech Posted August 27, 2011 Author Share Posted August 27, 2011 With any "recent" 3TB capable beta's, has anyone: 1) Upgraded their parity drive to a 3TB and successfully built parity onto it? 2) Subsequently upgraded a data disk to a 3TB and successfully rebuilt data onto it? In both cases, I'm upgrading from 2TB drives. Yes and Yes... are you having issues with this? Quote Link to comment
limetech Posted August 27, 2011 Author Share Posted August 27, 2011 driver: incorporate "explicit block device plugging" (http://lwn.net/Articles/438256/) This was the catch that avoided the kernel upgrade before, Tom? Yes. Quote Link to comment
limetech Posted August 27, 2011 Author Share Posted August 27, 2011 I have installed beta 12 and I get this: Aug 27 12:20:29 Unraid kernel: ata9: sas eh calling libata port error handler I have attached my syslog as this error is everywhere. Those messages are normal. 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.