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.

Thank you for your hard work I will test today.

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

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.

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.

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.

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.

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.

 

driver: incorporate "explicit block device plugging" (http://lwn.net/Articles/438256/)

 

This was the catch that avoided the kernel upgrade before, Tom?

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

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 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...

 

 

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!

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

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

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.

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.

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.

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

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.

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

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

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?

driver: incorporate "explicit block device plugging" (http://lwn.net/Articles/438256/)

 

This was the catch that avoided the kernel upgrade before, Tom?

 

Yes.

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.