unRAID Server Release 5.0-beta13 Available

[burnaby_boy]

I added an Intel PRO/1000 GT PCI Ethernet adapter card to my server and disabled the onboard Realtek chip. What a difference! - the delay in accessing the unRaid status page is gone and the transfer times - both ways - seem to have improved.

 

Spoke too soon - I tried to access the server this evening and there was a delay again. Initially most of the drives were shown as being spun down. I then refreshed the page and then it showed most of the drives as spinning - very peculiar. (syslog attached)

Cheers

 

Mine does it to. despite what people are saying with certain cards it seems to be waking the drives up to get the temp or something when accessing the main page.

 

Are you using any add-ons?

 

No add-ons being used here.

[generalz]

I added an Intel PRO/1000 GT PCI Ethernet adapter card to my server and disabled the onboard Realtek chip. What a difference! - the delay in accessing the unRaid status page is gone and the transfer times - both ways - seem to have improved.

 

Spoke too soon - I tried to access the server this evening and there was a delay again. Initially most of the drives were shown as being spun down. I then refreshed the page and then it showed most of the drives as spinning - very peculiar. (syslog attached)

Cheers

 

Mine does it to. despite what people are saying with certain cards it seems to be waking the drives up to get the temp or something when accessing the main page.

 

Are you using any add-ons?

 

 

Yes

Unmenu

Mysql

sabnzbd

couchpotato

sickbeard

transmission

crashplan

swapfile

 

 

however are all installed and run from the cache drive, so all the data drives will stay spun down for days at a time.

[Dimtar]

I am having a problem but I am not sure if it's with the beta or not. I will try to confirm but so far it looks like a folder that I created after I upgraded to version 13 drops out after a few hours and a reboot of UNRAID fixes it.

 

All the other folders work fine and so does it for a few hours. It gives me a folder not accessible error when I try to access it.

[pras1011]

I saw this is my syslog:

 

Nov  3 21:13:48 Unraid kernel: e1000e 0000:08:00.0: eth0: Detected Hardware Unit Hang:

Nov  3 21:13:48 Unraid kernel:  TDH                  <4>

Nov  3 21:13:48 Unraid kernel:  TDT                  <6>

Nov  3 21:13:48 Unraid kernel:  next_to_use          <6>

Nov  3 21:13:48 Unraid kernel:  next_to_clean        <4>

Nov  3 21:13:48 Unraid kernel: buffer_info[next_to_clean]:

Nov  3 21:13:48 Unraid kernel:  time_stamp          <1213d7c>

Nov  3 21:13:48 Unraid kernel:  next_to_watch        <4>

Nov  3 21:13:48 Unraid kernel:  jiffies              <1213de6>

Nov  3 21:13:48 Unraid kernel:  next_to_watch.status <0>

Nov  3 21:13:48 Unraid kernel: MAC Status            <80383>

Nov  3 21:13:48 Unraid kernel: PHY Status            <792d>

Nov  3 21:13:48 Unraid kernel: PHY 1000BASE-T Status  <3c00>

Nov  3 21:13:48 Unraid kernel: PHY Extended Status    <3000>

Nov  3 21:13:48 Unraid kernel: PCI Status            <10>

 

What does this mean?

[mejutty]

I can report to the delay in accessing front webpage as it waits for all the disks to spin up.  N36L is what I using.

[Kewjoe]

Seems something in Unmenu keeps my drives spinning. If I keep just the normal unraid screen up, my drives will go to sleep. If i keep an unmenu window open (open to my menu). My drives stay spinning.

[jbartlett]

Seems something in Unmenu keeps my drives spinning. If I keep just the normal unraid screen up, my drives will go to sleep. If i keep an unmenu window open (open to my menu). My drives stay spinning.

 

You'll want to report it in the Unmenu thread at http://lime-technology.com/forum/index.php?topic=5568.0 , doesn't belong here.

[Chris Pollard]

The spin-ups on access happened to me with a stock beta installation.

 

I think this happens in 12a too,  I sometimes hear drives spinning up when I access /Main anyway.

[aht961]

I hate to see others having the same issue as I have, but at least this seems to be more evidence that something is fundamentally broken with Linux Kernel 3.1.0, unRAID 5.0b13, LSI controller cards, and spindown/spinup.

 

Is there any thing new with regard to this problem and is Limetech aware of this problem at all? I have not seen any comments from him

[tr0910]

I have 3 servers running either b12a or b13 and all seem to be working fine.  One is:

 

Supermicro X9SCM-F

Intel i3-2100 and 4 gig RAM

Supermicro AOC-SASLP-MV8 8-Port

Norco 4224

mix of 3tb and 2tb drives

 

Other 2 are:

 

Asus m4a 785 m

AMD 140

2 gig RAM

all 2 tb drives

 

I hadn't planned on going 5beta but running 3tb drives forced the issue.  This is a production level system with the 2 AMD systems acting as backup servers to the Intel one.  Since we were using rsync as the transfer tool, it was just too much problem to run a mixed 4.7 and 5beta environment.  The file permissions had to be updated after every rsync.

[dgaschk]

I'm using the beta as a backup for the 4.7 primary using rsync. I don't share the backup copy so permissions is not an issue. I'm doing disk to disk backups so if a disk in the primary is lost I can physically replace the lost drive with the backup copy.

[speeding_ant]

Re: Disk spin up on page access. This has happened to me since a later 4 series upgrade. Have posted several logs a while ago, however no record of disks being spun up. It doesn't appear to be a chipset issue, this has happened in-between motherboard upgrades (from Intel to AMD).

 

It's quite frequent.

[jbartlett]

Re: Disk spin up on page access

 

I also have not seen any mention in my syslog of the drives spinning up when this happens. While I can frequently access the website without drive spinup after long periods of inactivity, when it does occur, it occurs only after a period of inactivity.

[Interstellar]

Bad news, after fixing my CPU scaling thing... I found this:

 

Nov  5 12:48:54 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network)

 

 

I'm guessing that Realtek bug is back, how do I go back to r8168 on b13?

 

Edit: Syslog attached.

syslog-2011-11-05.txt

[prostuff1]

Bad news, after fixing my CPU scaling thing... I found this:

 

Nov  5 12:48:54 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network)

 

 

I'm guessing that Realtek bug is back, how do I go back to r8168 on b13?

 

Edit: Syslog attached.

If your network seems to be working normally then I would not worry about that message to much

[BRiT]

Bad news, after fixing my CPU scaling thing... I found this:

 

Nov  5 12:48:54 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network)

 

 

I'm guessing that Realtek bug is back, how do I go back to r8168 on b13?

 

Edit: Syslog attached.

 

As Limetech has said, beta13 has an entirely new kernel and new NIC drivers. Continue using what it defaults to and report issues if you see any. Just because it's using r8169 does NOT mean it's an issue.

 

linux - I have been monitoring and testing the 3.1 development.  There are numerous driver changes.  In particular, mvsas seems far more robust.  Also r8169 has many changes, so in this release I have gone back to the kernel driver for Realtek devices. If you are using Realtek NIC's please report whether it still works or not with this release.

http://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.1

[WizADSL]

I just added an AOC-SASLP-MV8 to my system in order to consolidate several 2-port sata controllers, I was able to boot and start the array, but the syslog was being FILLED by lines like the ones below.  I'm talking on the order of 1 gig of syslog in the space of 10 minutes.  6 of my drives are on the MB controller and the other 5 where put on the AOC-SASLP-MV8, bios version is 3.1.0.22.  Initially I had a drive red-balled because I didn't have one of the cables seated properly but the syslog messages were always present.  I am using 2 reverse breakout cables to hook up drives.

 

[pre]Nov 5 02:04:39 Tower kernel: drivers/scsi/mvsas/mv_sas.c 2108:phy 3 ctrl sts=0x00199800.

Nov 5 02:04:39 Tower kernel: drivers/scsi/mvsas/mv_sas.c 2110:phy 3 irq sts = 0x01000000

Nov 5 02:04:39 Tower kernel: drivers/scsi/mvsas/mv_sas.c 2108:phy 3 ctrl sts=0x00199800.

Nov 5 02:04:39 Tower kernel: drivers/scsi/mvsas/mv_sas.c 2110:phy 3 irq sts = 0x01000000

Nov 5 02:04:39 Tower kernel: drivers/scsi/mvsas/mv_sas.c 2108:phy 3 ctrl sts=0x00199800.

Nov 5 02:04:39 Tower kernel: drivers/scsi/mvsas/mv_sas.c 2110:phy 3 irq sts = 0x01000000[/pre]

[Johnm]

I just added an AOC-SASLP-MV8

I am using 2 reverse breakout cables to hook up drives.

 

 

You would need Forward breakout cables to hook a SASLP-MV8 to a hard drives sata port.

[WizADSL]

I just added an AOC-SASLP-MV8

I am using 2 reverse breakout cables to hook up drives.

 

 

You would need Forward breakout cables to hook a SASLP-MV8 to a hard drives sata port.

 

I may have the terminology wrong, but the cables are made to go from the controller to the drives where the fanout is supposed to be on the drive side.

[kenoka]

I just added an AOC-SASLP-MV8

I am using 2 reverse breakout cables to hook up drives.

 

 

You would need Forward breakout cables to hook a SASLP-MV8 to a hard drives sata port.

 

I may have the terminology wrong, but the cables are made to go from the controller to the drives where the fanout is supposed to be on the drive side.

Both forward and reverse breakout cables have sata ports on one side and an SAS port on the other, but are not interchangeable because they're only meant to send data in one direction. Make sure you have the correct cable.

[tribble222]

I'm having a problem with user share permissions. I upgraded from 4.7. Unless I set my shares to "public" they seem to always be shared as "read-only", even if I give a particular user read/write permissions. I'm accessing the shares through a box running Ubuntu. Everything worked fine in 4.7 with this same setup. I did run the new permissions utils script but that didn't help. Any help appreciated, thanks.

[WallaceTech]

I am going to go back to 4.7.

 

I have been having some weird issues with NFS shares.

 

1) NFS share dropping out and needing to reboot Windows 7 to use them again

 

2) Create NFS Share A and B. Copy data to Share A and it shows up in Share B

 

 

[madburg]

May have found a bug,

 

I setup a Share as "Use cache disk: Only" added data to that cache only share, a day later I went back to change it to "Use cache disk: Yes", added 6 disks to "Included disk(s):", set allocation method to "Most-free" a "Split level: 1". Clicked "Apply" then clicked "Done". Executed the mover "Move Now", no data moved, tail log shows its skipping that share.

 

I repeated this with another share, same behavior. So seems you cannot switch from a cache only share to an array share.

 

I checked the flash\config\shares\cfg's, the cfg looks no different then a share that was originally setup as an array share... Rebooted unRAID, just will not move.

Problem is now, I cant delete the share as it is not empty so I cant even recreate it as a new array share to get over this bug.

 

Any suggestions?

[Johnm]

May have found a bug,

 

I setup a Share as "Use cache disk: Only" added data to that cache only share, a day later I went back to change it to "Use cache disk: Yes", added 6 disks to "Included disk(s):", set allocation method to "Most-free" a "Split level: 1". Clicked "Apply" then clicked "Done". Executed the mover "Move Now", no data moved, tail log shows its skipping that share.

 

I repeated this with another share, same behavior. So seems you cannot switch from a cache only share to an array share.

 

I checked the flash\config\shares\cfg's, the cfg looks no different then a share that was originally setup as an array share... Rebooted unRAID, just will not move.

Problem is now, I cant delete the share as it is not empty so I cant even recreate it as a new array share to get over this bug.

 

Any suggestions?

You could try manually moving the data from cache to a drive, delete the folder on the cache drive when empty. stop start array or reboot and then try and use the share and see what happens?

[MikeL]

It is looking like b13 didn't fix the SUPERMICRO AOC-SASLP-MV8 problems.

My system has crashed twice today while doing Parity check. Just like b12a did. Ran great for a while not a single issue, then Parity check, and bam nothing but problems.