unRAID Server release 4.5-beta4 available

[jimwhite]

did you read the first post at all? 

 

[erikatcuse]

Tom

 

The Supermicro AOC-SASLP-MV8 - 8 Sata PCI-E 4x non-raid controller card uses the Marvell 6480 chip which needs the mvsas driver.  Smino has one and in the hardware forum has posted his syslog.  It doesn't look the the mvsas driver is included in unraid.  Would it be possible to include it in the next beta?

 

Taking a look online I found this which I believe is the driver needed.  http://www.opensubscriber.com/message/[email protected]/8668946.html

 

Thanks

Erik

[limetech]

wget also won't work if they have a password on root.

 

The -beta5 version woks whether password set or not.

[limetech]

Tom

 

The Supermicro AOC-SASLP-MV8 - 8 Sata PCI-E 4x non-raid controller card uses the Marvell 6480 chip which needs the mvsas driver.  Smino has one and in the hardware forum has posted his syslog.  It doesn't look the the mvsas driver is included in unraid.  Would it be possible to include it in the next beta?

 

Taking a look online I found this which I believe is the driver needed.  http://www.opensubscriber.com/message/[email protected]/8668946.html

 

Thanks

Erik

 

Yes, added that in -beta5.

[limetech]

Yeah I understood that. I meant to post as well that is a good suggestion but one day Id like to fix the problem direct in uNRAID... it really shouldnt need to tell you 10,000 the same thing

 

The user share pseudo-file system currently may generate two "informational" messages:

 

1) the "duplicate" messages, and

2) a "cache disk full" message when the cache disk free space is below cache "min free space"

 

These message can be turned off as follows:

 

1) create the file "extra.cfg" in the 'config' directory on the Flash, with this line in it:

 

shfsExtra=-logging 0

 

2) reboot.

 

Both the 'extra.cfg' file and the 'shfsExtra' variable are for development purposes & there's no guarantee it will always work, but I won't change it until/unless a user control in the webGui is added to control logging.

[Two Wire]

did you read the first post at all?

 

 

Indeed I did. However, the posts following that led me to believe an argument was being made agninst going down that road.

[limetech]

My money is on a missing break statement following the spin up commands, so it then falls into the next case statement group, the spin down loop.

I'll bet you're right.   (Been there, done that, got the "T-shirt")

 

Race condition between spin-down poller thread and spin-up threads.

[Joe L.]

My money is on a missing break statement following the spin up commands, so it then falls into the next case statement group, the spin down loop.

I'll bet you're right.   (Been there, done that, got the "T-shirt")

 

Race condition between spin-down poller thread and spin-up threads.

I'm impressed... much harder to find and fix....  Coding a "race condition" is not easy... leaving out a "break" is so much easier...

 

Joe L.

[smino]

Thank you for removing private data from the syslog. That is great, and will save me alot of time.

Can we also have a button on the gui to zip and download the syslog file, instead of having to do a copy command to the usb drive from telnet?

 

Second, where is the list of next features to come?

[jdog09]

Bug:

 

I had a password that Contain ")" and "("  The Error code was 2 from the net ads command.    Only got the Beta4 to join the domain after changing my Enterprise Domain Admin password without these characters..

[JarDo]

I'm currently running beta-4.  I noticed the following in my syslog that I've never seen before.  Is this just beta debug stuff or is something going on with my server hardware that I should be concerned about.  I don't understand what these log entries are referring to.

 

Apr 17 16:13:13 UNRAID kernel: ------------[ cut here ]------------
Apr 17 16:13:13 UNRAID kernel: WARNING: at net/sched/sch_generic.c:226 dev_watchdog+0xf0/0x16d()
Apr 17 16:13:13 UNRAID kernel: NETDEV WATCHDOG: eth0 (e1000): transmit timed out
Apr 17 16:13:13 UNRAID kernel: Modules linked in: md_mod ata_piix piix ide_core sata_mv sata_sil libata e1000
Apr 17 16:13:13 UNRAID kernel: Pid: 10093, comm: shfs Not tainted 2.6.28.4-unRAID #3
Apr 17 16:13:13 UNRAID kernel: Call Trace:
Apr 17 16:13:13 UNRAID kernel: [] warn_slowpath+0x61/0x78
Apr 17 16:13:13 UNRAID kernel: [] update_curr+0x5c/0x95
Apr 17 16:13:13 UNRAID kernel: [] check_preempt_wakeup+0xbf/0xd6
Apr 17 16:13:13 UNRAID kernel: [] try_to_wake_up+0x11e/0x127
Apr 17 16:13:13 UNRAID kernel: [] restore_i387_fxsave+0x4d/0x5d
Apr 17 16:13:13 UNRAID kernel: [] strlcpy+0x14/0x41
Apr 17 16:13:13 UNRAID kernel: [] dev_watchdog+0xf0/0x16d
Apr 17 16:13:13 UNRAID kernel: [] read_tsc+0x6/0x22
Apr 17 16:13:13 UNRAID kernel: [] update_curr+0x5c/0x95
Apr 17 16:13:13 UNRAID kernel: [] hrtimer_run_pending+0x1d/0x92
Apr 17 16:13:13 UNRAID kernel: [] dev_watchdog+0x0/0x16d
Apr 17 16:13:13 UNRAID kernel: [] run_timer_softirq+0x107/0x15a
Apr 17 16:13:13 UNRAID kernel: [] __do_softirq+0x83/0x11e
Apr 17 16:13:13 UNRAID kernel: [] do_softirq+0x32/0x36
Apr 17 16:13:13 UNRAID kernel: [] smp_apic_timer_interrupt+0x6e/0x78
Apr 17 16:13:13 UNRAID kernel: [] apic_timer_interrupt+0x28/0x30
Apr 17 16:13:13 UNRAID kernel: [] system_call+0x0/0x3b
Apr 17 16:13:13 UNRAID kernel: ---[ end trace c8522f6d41e970e8 ]---

[Bigdady92]

version: 4.5-beta4

 

Getting a pages of these now:

Apr 19 07:38:15 ChainDog kernel: FAT: Directory bread(block 3876) failed
Apr 19 07:38:15 ChainDog kernel: FAT: Directory bread(block 3877) failed
Apr 19 07:38:15 ChainDog kernel: FAT: Directory bread(block 3878) failed
Apr 19 07:38:15 ChainDog kernel: FAT: Directory bread(block 3879) failed
Apr 19 07:40:15 ChainDog kernel: FAT: Directory bread(block 3872) failed
Apr 19 07:40:15 ChainDog kernel: FAT: Directory bread(block 3873) failed
Apr 19 07:40:15 ChainDog kernel: FAT: Directory bread(block 3874) failed
Apr 19 07:40:15 ChainDog kernel: FAT: Directory bread(block 3875) failed
Apr 19 07:40:15 ChainDog kernel: FAT: Directory bread(block 3876) failed
Apr 19 07:40:15 ChainDog kernel: FAT: Directory bread(block 3877) failed
Apr 19 07:40:15 ChainDog kernel: FAT: Directory bread(block 3878) failed
Apr 19 07:40:15 ChainDog kernel: FAT: Directory bread(block 3879) failed

 

 

My USB key dying?

 

[RobJ]

version: 4.5-beta4

 

Getting a pages of these now:

Apr 19 07:38:15 ChainDog kernel: FAT: Directory bread(block 3876) failed
Apr 19 07:38:15 ChainDog kernel: FAT: Directory bread(block 3877) failed

 

My USB key dying?

 

That usually always is your flash key, but it is premature to assume anything about what is wrong.  It can simply mean it was jostled loose, or a temporary loss of its IRQ, or ...

 

Need to see the syslog before you reboot (might need to save it to another drive).  Also need to find out what happens next when you reboot, will it be seen, will it fully boot, etc.  You *may* need to take it to a Windows machine and run the ScanDisk or Check Disk on it.

[RobJ]

I'm currently running beta-4.  I noticed the following in my syslog that I've never seen before.  Is this just beta debug stuff or is something going on with my server hardware that I should be concerned about.  I don't understand what these log entries are referring to.

 

That is not beta stuff.  It is more like a program crash, with apparently a recovery.  I would reboot though.

 

It appears it *may* be related to the network driver, but that is not conclusive.  Not much you can do but watch for a recurrence, and record what was happening when it occurred.  Also record (as you have) all of the messages produced, that seem coincident, including syslog messages within the previous minute.

[Bigdady92]

I'm currently running beta-4.  I noticed the following in my syslog that I've never seen before.  Is this just beta debug stuff or is something going on with my server hardware that I should be concerned about.  I don't understand what these log entries are referring to.

 

That is not beta stuff.  It is more like a program crash, with apparently a recovery.  I would reboot though.

 

It appears it *may* be related to the network driver, but that is not conclusive.  Not much you can do but watch for a recurrence, and record what was happening when it occurred.  Also record (as you have) all of the messages produced, that seem coincident, including syslog messages within the previous minute.

 

Saw that info on a search of the forums. I took the key out, moved it to a different usb port, raid is resync'n. If that problem crops up I'll repost with my syslog.

 

[jesuslovesbacon]

I just upped from 4.4.2. Everything seems to be working fine.

[Nyago123]

I'm running 4.5-beta4.  I'm not sure if this is beta specific or not... but just in case I'm posting here.

 

Not sure if this is a bug or another round of "High Water" allocation confusion, but I just added a disk to my unRAID array (well, technically I replaced a disk, after doing some manual shuffling to get the files off of an old one).  unRAID did a rebuild and extended the free space.

 

The starting layout is basically this:

Parity - 2 TB (a WD20EADS)

disk1 - 2 TB (also a WD20EADS), with 2 TB free (i.e. it's empty )

disk2 - 750GB, with 25 GB free

disk3 - 750GB, with 120GB free

disk4 - 750GB, with 134GB free

disk5 - 750GB, with 104GB free

cache - 400GB

 

My shares are set to a split level of 1 or 2 and all are set to "High Water" allocation.

 

I copied about 110GB of data over to the cache and began a "Move Now".  Guess which disk it began writing to?  I'd think with the new disk in place it would do the math and could only conclude disk1 was the place to go, yet it started writing to disk3. 

 

Under what scenario does this make any sense?  Is unRAID "remembering" some previous high water mark?

 

Edit: One other detail... the files initially being moved are associated with a share with a split level of 1.  The share is "Music" and the files are under a folder which are under another category folder, which resides under the Music share.

[mashles]

Edit: One other detail... the files initially being moved are associated with a share with a split level of 1.  The share is "Music" and the files are under a folder which are under another category folder, which resides under the Music share.

 

So you are copying the folders into a folder 2 levels deep, with a split level of 1 on the share? That means that its going to copy them onto the disk that owns the folder you are copying them into, in your case the category folder. Split level of 1 means it will only split the first level of folders under the share, any deeper than that will stay on the same disk. So all the music within each category in your case are on the same disk.

 

Let me know if I have misinterpreted what you said though.

[Nyago123]

So you are copying the folders into a folder 2 levels deep, with a split level of 1 on the share? That means that its going to copy them onto the disk that owns the folder you are copying them into, in your case the category folder. Split level of 1 means it will only split the first level of folders under the share, any deeper than that will stay on the same disk. So all the music within each category in your case are on the same disk.

 

Ah I see.  I've set the split level to 2.  I think I had an "n-1" bug in my brain.    Thanks.

 

[fitbrit]

This version works very well for me. I had a problem with 4.3.3 where I'd get a kernel panic when I tried to 'spin up all disks'. I thought it was my PSU not supplying enough juice (3 - rail, 650 W Antec). However, since i upgraded to this beta, I can spin up and down as many times as I like!