Tom, just wondering if you have any thoughts of when RC3 and/or 5 Final is going to be available.

 

Reason  I ask is I have recently purchased M1015 flashed with LSI firmware in IT mode in transit to me as I type this.  Just wondering if I should go ahead and upgrade to RC2 (from beta 13) when it arrives or if it's close to being ready just hold off until RC3 or Final is available?

He might be able to give you a time but frankly he might be completely wrong/off.

 

If LSI is confirmed working in RC2 (which it appears to be) then I would suggest using it until further notice.

Tom, just wondering if you have any thoughts of when RC3 and/or 5 Final is going to be available.

 

Reason  I ask is I have recently purchased M1015 flashed with LSI firmware in IT mode in transit to me as I type this.  Just wondering if I should go ahead and upgrade to RC2 (from beta 13) when it arrives or if it's close to being ready just hold off until RC3 or Final is available?

He might be able to give you a time but frankly he might be completely wrong/off.

 

If LSI is confirmed working in RC2 (which it appears to be) then I would suggest using it until further notice.

 

That's fine if he doesn't know or can't be specific.  I've gone this long without the card if he thinks it might me available in the next week or so I can hold off and even if he's wrong and it's no biggie.  I'd just hate to get the card in the next day or to, do the upgrade this weekend then see one of the new releases be available on Monday... as always seems to happen with me :-)

 

I think this answers my previous question about NFS, but not explicitly. Does anyone have experience with RC2 and NFS and is the stale file handle problem still present in RC2?

 

Since I can get nfs to fall over in 15 seconds, I haven't run it for long enough to find out whether the stale handle problem is still present.

Regarding RC2-test:

 

Mounted the array, spun down all drives, spun up, spun down again then initiated a parity check.

 

This sequence always led to those terrible  errors related to mpt2sas driver and kernel 3.1+. In RC2-test this didn't happen!!! The emhttp and the md driver correctly stated the power status from the drives and woke them up prior to the access, avoiding the bug to happen!

 

Thank you so much, Tom!

 

PS. This is an early report, but parity check seem a bit faster too, about 10MB/s faster than in B12a. Will report again when the check finishes.

 

Ok, the parity check finished, and the medium speed was 70MB/s of rc2 versus 63MB/s from 12a. LSI 1068E based card. This is a good speed improvement.

 

About the AFP problems people are experiencing, I have a teory based on my setup experience: the database scheme used in AFP don't play well with the shfs "user" mount. My speculation is that  if the .AppleDB folder that contain the database is stored on a drive that is in standby, the error is raised because netatalk query timed out. I consistently have these errors with shares and not with disk exports.

 

If someone could test this out and report the results, I would be glad.

Thanks for the update!

 

I only use smb. Rc2 working good on my 10 drive system. I have 4 drives on my BR10i one being the cache and 6 on the motherboard one being a 3 TB parity drive. All drives spin up and down, wake on access and spin down individually. Read and write speeds seem to be the same or better. Started and canceled a parity test {no correct) speed was normal.

 

But I do have a problem:

 

The array needs to be started manually

 

There is no startState= in my disk.cfg file even if I select no for "Enable auto start:" There are no plugins running. No unMenu. I have tried applying this setting many ways:

 

array on-line

array off-line

array on-line "Maintenance mode"

set no reboot, set yes reboot, set yes again reboot

 

I know the file is updating because the spin down can be changed. I cut and pasted the line startState="STOPPED" to disk.cfg in the same position as an old backup. Even if I select no for "Enable auto start" and apply the line gets removed.

 

What is the value of the variable startState that allows the array to auto start?

 

Reed

Same for me

But I do have a problem:

 

The array needs to be started manually

 

There is no startState= in my disk.cfg file even if I select no for "Enable auto start:" There are no plugins running. No unMenu. I have tried applying this setting many ways:

 

array on-line

array off-line

array on-line "Maintenance mode"

set no reboot, set yes reboot, set yes again reboot

 

Exactly my problem also.  I have tried many combinations of setting No / Apply / Reboot / Yes / Apply / Reboot / etc.  The only way that I can get a reliable auto start is with 5b14 or 5.0-rc1.  Putting either of those back (without any other changes) and the problem goes away.

ditto on no auto-start.  Of course this is really just an annoyance (for me) since I normally am not cycling the server.  But for folks who shutdown nightly I can see how that is a huge annoyance.

But I do have a problem:

 

The array needs to be started manually

 

There is no startState= in my disk.cfg file even if I select no for "Enable auto start:" There are no plugins running. No unMenu. I have tried applying this setting many ways:

 

array on-line

array off-line

array on-line "Maintenance mode"

set no reboot, set yes reboot, set yes again reboot

 

Exactly my problem also.  I have tried many combinations of setting No / Apply / Reboot / Yes / Apply / Reboot / etc.  The only way that I can get a reliable auto start is with 5b14 or 5.0-rc1.  Putting either of those back (without any other changes) and the problem goes away.

 

Although it shouldn't be necessary (the problem should be fixed), wouldn't putting an "md start" in your go file work around this in the meantime?

 

But I do have a problem:

 

The array needs to be started manually

 

There is no startState= in my disk.cfg file even if I select no for "Enable auto start:" There are no plugins running. No unMenu. I have tried applying this setting many ways:

 

array on-line

array off-line

array on-line "Maintenance mode"

set no reboot, set yes reboot, set yes again reboot

 

Exactly my problem also.  I have tried many combinations of setting No / Apply / Reboot / Yes / Apply / Reboot / etc.  The only way that I can get a reliable auto start is with 5b14 or 5.0-rc1.  Putting either of those back (without any other changes) and the problem goes away.

 

Although it shouldn't be necessary (the problem should be fixed), wouldn't putting an "md start" in your go file work around this in the meantime?

No, probably not...

1. the "md" driver might not even be loaded.

2. the mount points for the disks might not yet exist

3. the disks might not be mounted on the mount points

4. SMB, NFS networkng miht only have the flash drive defined.

 

You really need to start the array via the management console.  (or, have it auto-start as it is supposed to)

Joe L.

But I do have a problem:

 

The array needs to be started manually

 

 

Yes this is a bug I introduced in -rc2-test, and fixed in -rc2.

I think this answers my previous question about NFS, but not explicitly. Does anyone have experience with RC2 and NFS and is the stale file handle problem still present in RC2?

 

Since I can get nfs to fall over in 15 seconds, I haven't run it for long enough to find out whether the stale handle problem is still present.

 

I'll try and set this up in ubuntu.  Happen with both disk shares and user shares?

But I do have a problem:

 

The array needs to be started manually

 

 

Yes this is a bug I introduced in -rc2-test, and fixed in -rc2.

 

Thanks Tom!

 

Reed

Upgraded from 4.7 to 5.0rc1 over the weekend. My first time on the 5.0 version. Other than not being able to access the folders/shares until after I rebooted my Windows 7 client machine the upgrade went without a hitch and so far seems to be running like a champion.

 

I need to look into whether my plugins are still there etc and will try to preclear a 2TB HDD during the week.

 

System:

Lian Li PC-A77FB

Gigabyte GA-880GMA-UD2H

SUPERMICRO AOC-SASLP-MV8 x 2

Hitachi Deskstar 5k3000/7k3000 x 10

 

HDDs seem to spindown fine.

 

thanks

 

Alex

 

Would you mind doing a test on your setup with RC1 and run a parity check, non correcting as you can stop it after the test is done. Would like to see what your parity speeds are.

I upgraded from 4.7 and only got ~17.50MB/sec. Someone else on this thread also reported that kind of speed and was also using SUPERMICRO AOC-SASLP-MV8 cards.

I use those cards also, if yours is slow then maybe these cards are the comman factor causing the slowdown.

 

Mark

 

I've been able to successfully upgrade my SASLPs to .21 firmware from .15 due to an updated Gigabyte motherboard BIOS.

 

I am running a parity check (no correct) which is currently averaging 45 MB/sec

 

in my array I have:

 

Hitachi 7200 2TB Parity drive

Hitachi 5400 2TB data drive x 6

Hitachi 7200 2TB data drive x 3

 

hth

 

Alex

 

Anyone else having trouble with mover?

 

My entire systems crashes when mover is initiated, either manually or via cron, overnight 

Anyone else having trouble with mover?

 

My entire systems crashes when mover is initiated, either manually or via cron, overnight 

 

Need a syslog.

But for folks who shutdown nightly I can see how that is a huge annoyance.

 

... or those, like me, who suffer lots of power cuts.

But I do have a problem:

 

The array needs to be started manually

 

 

Yes this is a bug I introduced in -rc2-test, and fixed in -rc2.

Thanks Tom.  I look forward to testing.

Since I can get nfs to fall over in 15 seconds, I haven't run it for long enough to find out whether the stale handle problem is still present.

 

I'll try and set this up in ubuntu.  Happen with both disk shares and user shares?

Thank you, Tom!

 

Yes, it occurs with both disk and user shares.  I have two nautilus windows open, one on an unRAID share, and one on a local device.  I drag a file from the unRAID share to the local device.  It starts copying (the test I've just done with a user share reports 116.7MB copied) but then hangs up.  I will try doing the same thing from command line.

 

As far as I can tell, this happens with any version of unRAID using a 3+ kernel.  As I've stated before, there is no obvious clue in the syslog.

 

Edit:

A little more information:

I tried copying to a laptop (also running Ubuntu 12.04), but using a wireless connection.  This doesn't hang.

 

I then tried throttling my desktop back to 100Mb, and this also copies to completion ... slowly.

It is also clear that the server is not affected by the problem ... I just need to reboot the client (or use another client).  Perhaps this is a fault in the Ubuntu ethernet drivers and it's just that the 3.x kernels in unRAID are able to push data down the cable more quickly than the 2.x kernels do?

 

I do know that the raw bandwidth between my unRAID server and my main Ubuntu desktop achieves more than 110 MB/s according to iperf.

 

Also, copies to the server complete without problem ... at 80+MB/sec to cache drive.

 

During this test, I've just encountered a 'stale nfs file handle' in RC2, so this problem is not resolved ... perhaps also an ubuntu problem?  Dismounting and remounting the drive at the ubuntu client usually re-instates operation.

... or those, like me, who suffer lots of power cuts.

 

UPS? We get pretty frequent power outages, which luckily only last 10-20 minutes. Having a UPS has saved me a lot of headaches with unRAID.

... or those, like me, who suffer lots of power cuts.

 

UPS? We get pretty frequent power outages, which luckily only last 10-20 minutes. Having a UPS has saved me a lot of headaches with unRAID.

 

Lucky you - ours last 2 hours, on average ... sometimes much longer.  I have my UPS configured so that the server shuts down after 5 minutes - this gives me time to start the generator if I'm home.

Whew, where do you guys live?! I live "way out in the sticks" in a little redneck town, and power very rarily ever goes out. I mean, I know being a smaller town there is less strain on the power plants for supply/demand, but holy smokes, lol

But I do have a problem:

 

The array needs to be started manually

 

 

Yes this is a bug I introduced in -rc2-test, and fixed in -rc2.

 

 

Glad i saw this, was starting to pull my hair out a bit...

 

regarding NFS, have you tried other distros? Slackware, Knoppix, Redhat, Fedora, etc, etc?

 

Is it possible to use other drivers for the NICs?

 

I can whip up a VM and linux and have a look? Not that i know much about Linux or anything about NFS

Whew, where do you guys live?! I live "way out in the sticks" in a little redneck town, and power very rarily ever goes out.

 

I live in a small city (smaller than most UK towns!) in Philippines.  I am posting this immediately after the power returned following a 1hr 35mins outage.  Not too bad, it's now 2pm, we haven't had a cut since yesterday evening!!

 

Later:

... and ten minutes after that it went off for another hour!

Anyone else having trouble with mover?

 

My entire systems crashes when mover is initiated, either manually or via cron, overnight 

 

Need a syslog.

 

Where can i find the system log after rebooting Tom? Sorry, not really used them before.