unRAID Server Release 5.0-rc1 Available


332 posts in this topic Last Reply

Recommended Posts

  • Replies 331
  • Created
  • Last Reply

Top Posters In This Topic

Why not get a new card?

 

LSI is built onto my and many other's enterprise level Server motherboard(s).

 

As far as the LSI issue not being an unRAID issue, the point everyone seems to be overlooking is how it's up to Limetech to select what version of the kernel to use. Many of us would be satisfied if Limetech simply made an RC/Final 5.0 using a STABLE Linux 3.0.x kernel.

 

I wonder if perhaps the code that unRAID uses to spin-up the drives might be at fault. One way of testing this is to have the drives-spun down and then use external tools to spinup drives.

 

Reverting back to a 3.0 kernel will break a bunch of other hardware support, then I'll have a completely different set of people yelling at me.

 

As is apparent I've been more-or-less ignoring this LSI issue for these reasons:

- these cards were very expensive when they first came out, so I never purchased one

- lots of talk on various forums of people re-flashing the cards, so I thought the issue might go away on it's own

- lots of talk on various forums of it working on some kernels, and not on others, so I thought a kernel update might solve the issue

- LSI is notorious for requiring download of their custom driver, though apparently this is not the case here

- very few support emails complaining of this issue (far more emails for other issues)

 

I'm thinking now this is an unRaid-specific problem, not linux problem, so if you have this card, please see my previous post and we'll figure out what's happening.

 

 

Also - unRaid uses the 'hdparm -y' command to spin down a drive.  Read/write commands are just sent to a spun-down drive and it's up to the drive to spin up, so this is a strange problem...

 

I've compiled all kernel change logs since 3.0.3 to help track this issue. Maybe this is a hdparm issue, not kernel one.

 

http://lime-technology.com/forum/index.php?topic=19831.0

 

Link to post

For those with a m1015/br10i,

 

A) If the drives are never spun down, does everything work?

 

B) try this experiment:

 

- Stop the array

 

- note device id of one of the data drives attached to a m1015/br10i (for purposes of this post, let's say its "sdc").

 

- now type this sequence using above device id:

 

mkdir /x

mount /dev/sdc1 /x

ls /x                                  <--- should list your top level dirs here

hdparm -y /dev/sdc          <--- should spin down drive

ls -R /x                              <--- should spin up and list all files on the disk

umount /x

 

Let me know if this sequence works and does not produce any syslog entries.

 

nothing im my syslog

Link to post

For those with a m1015/br10i,

 

A) If the drives are never spun down, does everything work?

 

B) try this experiment:

 

- Stop the array

 

- note device id of one of the data drives attached to a m1015/br10i (for purposes of this post, let's say its "sdc").

 

- now type this sequence using above device id:

 

mkdir /x

mount /dev/sdc1 /x

ls /x                                  <--- should list your top level dirs here

hdparm -y /dev/sdc          <--- should spin down drive

ls -R /x                              <--- should spin up and list all files on the disk

umount /x

 

Let me know if this sequence works and does not produce any syslog entries.

 

nothing im my syslog

 

Thank you.  One more experiment if you don't mind.

 

Go and set the spindown delay for all the drives to be "never".  Then reboot server.  Upon reboot, look at the Main page and take note of the device id's of the disks attached to LSI controller, eg, sda, sdb, etc.

 

Next, from windows, navigate to a disk share of one of the drives attached to LSI controller, and go down the directory tree until you see a list of large files - do not click or copy any of those large files just yet.

 

Now from telnet session, manually spin down that drive (do not use Spin Down button on webGui), e.g.:

 

hdparm -y /dev/sdb

 

(instead of 'sdb' use whatever device id is assigned to disk you've navigated to)

 

You should hear the disk spin down.

 

Now go back to windows and drag one of the large files to, say the desktop.  What we're trying to do is have the disk spin up as a result of disk read requests.

 

Tell me if this works with no system log error messages.

Link to post

It is the fault of unRaid code. And Tom has showed clearly just how much time he puts into the project. First by not producing in the timeline he has spoken about and secondly to ask what post, when it was clearly brought up MANY time in many beta's and many spent the time to post their syslogs. Shame on you Tom. To spend 30mins on a kernel update and marking as RC to make the community believe v5 has the major bugs worked out...

 

To those who believe there are no other products out there like unRAID, your right they actually work, there is support with timelines, and their betas don't last years. Yes some have weak points & some have stronger points in certain areas. A cool idea is only cool for so long. And all this is just not cool.

 

One of unRaid strong points is (was) in sleeping drives, and really needs either a full rewrite or overhaul in that code.

 

A little harsh don't you think.  If you know of other programs that do what unraid does than use them and stop complaining about Tom and unraid. 

 

The problem with a timeline is this exact problem.  Something doesn't work for you or someone else and you want Tom/LimeTech to fix YOUR problem before anything else.  This happened with adding 3TB support also I believe.  Not saying this is right or wrong but if you need everything working or want something added that wasn't planed it messes everything up.

 

IMO I think he should release 5.0 as stable, which I think it is from the little I know, which is very little.  Post that it DOESN'T work with LSI cards as of now.  That will let more people test it out, he can work out any bugs that pop up and at the same time work on 5.1 to try and fix the LSI issue.  5.1 can be just for fixing LSI.  I will shut up now since I really have no idea what i'm talking about, I just know that Tom has worked hard and unraid works great for me.

 

 

Link to post

For those with a m1015/br10i,

 

A) If the drives are never spun down, does everything work?

 

B) try this experiment:

 

- Stop the array

 

- note device id of one of the data drives attached to a m1015/br10i (for purposes of this post, let's say its "sdc").

 

- now type this sequence using above device id:

 

mkdir /x

mount /dev/sdc1 /x

ls /x                                  <--- should list your top level dirs here

hdparm -y /dev/sdc          <--- should spin down drive

ls -R /x                              <--- should spin up and list all files on the disk

umount /x

 

Let me know if this sequence works and does not produce any syslog entries.

 

nothing im my syslog

 

Thank you.  One more experiment if you don't mind.

 

Go and set the spindown delay for all the drives to be "never".  Then reboot server.  Upon reboot, look at the Main page and take note of the device id's of the disks attached to LSI controller, eg, sda, sdb, etc.

 

Next, from windows, navigate to a disk share of one of the drives attached to LSI controller, and go down the directory tree until you see a list of large files - do not click or copy any of those large files just yet.

 

Now from telnet session, manually spin down that drive (do not use Spin Down button on webGui), e.g.:

 

hdparm -y /dev/sdb

 

(instead of 'sdb' use whatever device id is assigned to disk you've navigated to)

 

You should hear the disk spin down.

 

Now go back to windows and drag one of the large files to, say the desktop.  What we're trying to do is have the disk spin up as a result of disk read requests.

 

Tell me if this works with no system log error messages.

 

sorry wasnt thinking i ran the test on B12 i upgraded to RC1 and reran and got this

 

Apr 28 15:21:49 server kernel: sd 0:0:0:0: [sdc] Device not ready

Apr 28 15:21:49 server kernel: sd 0:0:0:0: [sdc]  Result: hostbyte=0x00 driverbyte=0x08

Apr 28 15:21:49 server kernel: sd 0:0:0:0: [sdc]  Sense Key : 0x2 [current]

Apr 28 15:21:49 server kernel: sd 0:0:0:0: [sdc]  ASC=0x4 ASCQ=0x2

Apr 28 15:21:49 server kernel: sd 0:0:0:0: [sdc] CDB: cdb[0]=0x28: 28 00 00 00 00 00 00 00 20 00

Apr 28 15:21:49 server kernel: end_request: I/O error, dev sdc, sector 0

Link to post

Just a simple question from a person who loves unRaid but is hesitant to upgrade:

 

I am using the following in my system:

 

Motherboard Gigabyte GA-MA785GM-US2H

SAS/SATA HBA SuperMicro AOC SASLP MV8

 

Can anyone tell me if either of these components are based on  the "LSI chipset"; or am I good to go when I get the nerve?

 

I don't believe any other components should matter.

Link to post

Just a data point...

 

My 12TB server set up -

  • Asrock H67M-ITX, i3-2125 CPU, 4GB RAM;
     

  • four drives on AOC-SASLP-MV8 (known to be good with recent betas) remainder on the motherboard;
     

  • drives are 6 data x 2TB, parity 2TB, cache 1TB.

All good with this release.  Parity check 6 hrs 25 minutes.  I'm happy.  :)

 

Thank you Tom.

Link to post

Just a simple question from a person who loves unRaid but is hesitant to upgrade:

 

I am using the following in my system:

 

Motherboard Gigabyte GA-MA785GM-US2H

SAS/SATA HBA SuperMicro AOC SASLP MV8

 

Can anyone tell me if either of these components are based on  the "LSI chipset"; or am I good to go when I get the nerve?

 

I don't believe any other components should matter.

 

I know this is fine, I have one

SuperMicro AOC SASLP MV8

Link to post

I followed the instructions for upgrading from b14 to rc1.  When I rebooted, my parity and disk drives were not assigned and the message displayed is "Stopped. No Devices".  My flash drive and cache drive showed up and were properly assigned.  My parity/disk drives all show up in the drop down lists for each drive and I know exactly where to assign each disk, but I don't want to assign them and start the array without checking in first to see if it's the proper procedure.  I would hate to lose 10TB of data.

Link to post

For those with a m1015/br10i,

 

A) If the drives are never spun down, does everything work?

 

B) try this experiment:

 

- Stop the array

 

- note device id of one of the data drives attached to a m1015/br10i (for purposes of this post, let's say its "sdc").

 

- now type this sequence using above device id:

 

mkdir /x

mount /dev/sdc1 /x

ls /x                                  <--- should list your top level dirs here

hdparm -y /dev/sdc          <--- should spin down drive

ls -R /x                              <--- should spin up and list all files on the disk

umount /x

 

Let me know if this sequence works and does not produce any syslog entries.

 

Here's a sample output from the terminal session:

root@THOR:~# mount /dev/sdg1 /x

root@THOR:~# ls /x

TV_SHOWS/

root@THOR:~# hdparm -y /dev/sdg

 

/dev/sdg:

issuing standby command

root@THOR:~# ls -R /x

/x:

/bin/ls: reading directory /x: Input/output error

root@THOR:~# umount /x

root@THOR:~# mount /dev/sdn1 /x

root@THOR:~# ls /x

DVD/

root@THOR:~# hdparm -y /dev/sdn

 

/dev/sdn:

issuing standby command

root@THOR:~# ls -R /x

/x:

/bin/ls: reading directory /x: Input/output error

 

When I restarted the array, the 3 drives I ran those commands on, came up unformatted showing 2 errors each.

 

Syslog attached.

 

syslog.zip

Link to post

I followed the instructions for upgrading from b14 to rc1.  When I rebooted, my parity and disk drives were not assigned and the message displayed is "Stopped. No Devices".  My flash drive and cache drive showed up and were properly assigned.  My parity/disk drives all show up in the drop down lists for each drive and I know exactly where to assign each disk, but I don't want to assign them and start the array without checking in first to see if it's the proper procedure.  I would hate to lose 10TB of data.

 

Exact same thing happened to me, but I have been upgrading/rebooting all day long trying to test a few things out so i thought it was something i caused. I just assigned the drives again in the correct spot and started the array, all of that data was there but it is having to rebuilt parity.

Link to post

Does anyone know if the SMB changes in RC1 fix the problems with robocopy?

 

In the betas, robocopy fails after moving the first file in a batch with the following error message:

 

2012/04/28 11:06:06 ERROR 5 (0x00000005) Changing File Attributes \\INARA\UserShare\

Access is denied.

 

Then it just retries and always gets the same message.

 

*Don't jump on me, I'm just asking the question so that I don't have to try the RC and then revert back to 4.7 again.  :)

 

Try this fix:  http://www.luisrocha.net/2008/12/robocopy-error-error-5-0x00000005.html

Link to post

For those with a m1015/br10i,

 

A) If the drives are never spun down, does everything work?

 

B) try this experiment:

 

- Stop the array

 

- note device id of one of the data drives attached to a m1015/br10i (for purposes of this post, let's say its "sdc").

 

- now type this sequence using above device id:

 

mkdir /x

mount /dev/sdc1 /x

ls /x                                  <--- should list your top level dirs here

hdparm -y /dev/sdc          <--- should spin down drive

ls -R /x                              <--- should spin up and list all files on the disk

umount /x

 

Let me know if this sequence works and does not produce any syslog entries.

 

Here's a sample output from the terminal session:

root@THOR:~# mount /dev/sdg1 /x

root@THOR:~# ls /x

TV_SHOWS/

root@THOR:~# hdparm -y /dev/sdg

 

/dev/sdg:

issuing standby command

root@THOR:~# ls -R /x

/x:

/bin/ls: reading directory /x: Input/output error

root@THOR:~# umount /x

root@THOR:~# mount /dev/sdn1 /x

root@THOR:~# ls /x

DVD/

root@THOR:~# hdparm -y /dev/sdn

 

/dev/sdn:

issuing standby command

root@THOR:~# ls -R /x

/x:

/bin/ls: reading directory /x: Input/output error

 

When I restarted the array, the 3 drives I ran those commands on, came up unformatted showing 2 errors each.

 

Syslog attached.

 

Thank you for that information.  One more experiment, replace this command:

 

hdparm -y /dev/sdc

 

with this:

 

hdparm -S1 /dev/sdc

 

This will set the internal drive spin down delay to it's minimum value (5 seconds).  After 5 sec you should hear the disk spin down.  Now repeat trying to read from that spun down disk and let's see if this also results in syslog errors.

Link to post

i seem to be getting an error that i have not seen in the past

 

 

Apr 28 19:17:25 Tower in.telnetd[13109]: connect from 192.168.0.100 (192.168.0.100)

Apr 28 19:18:25 Tower kernel: scsi_verify_blk_ioctl: 32 callbacks suppressed

Apr 28 19:18:25 Tower kernel: hdparm: sending ioctl 2285 to a partition!

Apr 28 19:18:42 Tower last message repeated 5 times

Apr 28 19:18:42 Tower kernel: smartctl: sending ioctl 2285 to a partition!

Apr 28 19:18:42 Tower last message repeated 7 times

Apr 28 19:19:42 Tower kernel: scsi_verify_blk_ioctl: 32 callbacks suppressed

Apr 28 19:19:42 Tower kernel: hdparm: sending ioctl 2285 to a partition!

Apr 28 19:19:58 Tower last message repeated 5 times

Apr 28 19:19:58 Tower kernel: smartctl: sending ioctl 2285 to a partition!

Apr 28 19:19:58 Tower last message repeated 7 times

Apr 28 19:20:43 Tower in.telnetd[16269]: connect from 192.168.0.100 (192.168.0.100)

Apr 28 19:20:54 Tower login[16385]: invalid password for 'UNKNOWN'  on '/dev/pts/0' from '192.168.0.100'

Apr 28 19:20:57 Tower login[16385]: ROOT LOGIN  on '/dev/pts/0' from '192.168.0.100'

Apr 28 19:20:58 Tower kernel: scsi_verify_blk_ioctl: 32 callbacks suppressed

Apr 28 19:20:58 Tower kernel: hdparm: sending ioctl 2285 to a partition!

Apr 28 19:21:15 Tower last message repeated 5 times

Apr 28 19:21:15 Tower kernel: smartctl: sending ioctl 2285 to a partition!

Apr 28 19:21:15 Tower last message repeated 7 times

Apr 28 19:22:15 Tower kernel: scsi_verify_blk_ioctl: 32 callbacks suppressed

Apr 28 19:22:15 Tower kernel: hdparm: sending ioctl 2285 to a partition!

Apr 28 19:22:32 Tower last message repeated 5 times

Apr 28 19:22:32 Tower kernel: smartctl: sending ioctl 2285 to a partition!

Apr 28 19:22:32 Tower last message repeated 7 times

Apr 28 19:23:32 Tower kernel: scsi_verify_blk_ioctl: 32 callbacks suppressed

Apr 28 19:23:32 Tower kernel: hdparm: sending ioctl 2285 to a partition!

Apr 28 19:23:53 Tower last message repeated 5 times

Apr 28 19:23:53 Tower kernel: smartctl: sending ioctl 2285 to a partition!

Apr 28 19:23:53 Tower last message repeated 7 times

Apr 28 19:24:53 Tower kernel: scsi_verify_blk_ioctl: 32 callbacks suppressed

Apr 28 19:24:53 Tower kernel: hdparm: sending ioctl 2285 to a partition!

Apr 28 19:25:09 Tower last message repeated 5 times

Apr 28 19:25:09 Tower kernel: smartctl: sending ioctl 2285 to a partition!

Apr 28 19:25:09 Tower last message repeated 7 times

Apr 28 19:26:09 Tower kernel: scsi_verify_blk_ioctl: 32 callbacks suppressed

Apr 28 19:26:09 Tower kernel: hdparm: sending ioctl 2285 to a partition!

syslog-2012-04-28.txt

Link to post

i seem to be getting an error that i have not seen in the past

 

 

Apr 28 19:17:25 Tower in.telnetd[13109]: connect from 192.168.0.100 (192.168.0.100)

Apr 28 19:18:25 Tower kernel: scsi_verify_blk_ioctl: 32 callbacks suppressed

Apr 28 19:18:25 Tower kernel: hdparm: sending ioctl 2285 to a partition!

Apr 28 19:18:42 Tower last message repeated 5 times

Apr 28 19:18:42 Tower kernel: smartctl: sending ioctl 2285 to a partition!

Apr 28 19:18:42 Tower last message repeated 7 times

Apr 28 19:19:42 Tower kernel: scsi_verify_blk_ioctl: 32 callbacks suppressed

Apr 28 19:19:42 Tower kernel: hdparm: sending ioctl 2285 to a partition!

Apr 28 19:19:58 Tower last message repeated 5 times

Apr 28 19:19:58 Tower kernel: smartctl: sending ioctl 2285 to a partition!

Apr 28 19:19:58 Tower last message repeated 7 times

Apr 28 19:20:43 Tower in.telnetd[16269]: connect from 192.168.0.100 (192.168.0.100)

Apr 28 19:20:54 Tower login[16385]: invalid password for 'UNKNOWN'  on '/dev/pts/0' from '192.168.0.100'

Apr 28 19:20:57 Tower login[16385]: ROOT LOGIN  on '/dev/pts/0' from '192.168.0.100'

Apr 28 19:20:58 Tower kernel: scsi_verify_blk_ioctl: 32 callbacks suppressed

Apr 28 19:20:58 Tower kernel: hdparm: sending ioctl 2285 to a partition!

Apr 28 19:21:15 Tower last message repeated 5 times

Apr 28 19:21:15 Tower kernel: smartctl: sending ioctl 2285 to a partition!

Apr 28 19:21:15 Tower last message repeated 7 times

Apr 28 19:22:15 Tower kernel: scsi_verify_blk_ioctl: 32 callbacks suppressed

Apr 28 19:22:15 Tower kernel: hdparm: sending ioctl 2285 to a partition!

Apr 28 19:22:32 Tower last message repeated 5 times

Apr 28 19:22:32 Tower kernel: smartctl: sending ioctl 2285 to a partition!

Apr 28 19:22:32 Tower last message repeated 7 times

Apr 28 19:23:32 Tower kernel: scsi_verify_blk_ioctl: 32 callbacks suppressed

Apr 28 19:23:32 Tower kernel: hdparm: sending ioctl 2285 to a partition!

Apr 28 19:23:53 Tower last message repeated 5 times

Apr 28 19:23:53 Tower kernel: smartctl: sending ioctl 2285 to a partition!

Apr 28 19:23:53 Tower last message repeated 7 times

Apr 28 19:24:53 Tower kernel: scsi_verify_blk_ioctl: 32 callbacks suppressed

Apr 28 19:24:53 Tower kernel: hdparm: sending ioctl 2285 to a partition!

Apr 28 19:25:09 Tower last message repeated 5 times

Apr 28 19:25:09 Tower kernel: smartctl: sending ioctl 2285 to a partition!

Apr 28 19:25:09 Tower last message repeated 7 times

Apr 28 19:26:09 Tower kernel: scsi_verify_blk_ioctl: 32 callbacks suppressed

Apr 28 19:26:09 Tower kernel: hdparm: sending ioctl 2285 to a partition!

 

The offending line is:

smartctl: sending ioctl 2285 to a partition!

 

This is probably a bug in one of your plugins.  It's possible it's been around for a while, but unreported, and the guy writing the driver got around to flagging this error.  I can try and dig up what ioctl 2285 (0x8ED) refers to, but bigger fish to fry at the moment.  It would help to isolate which plugin is causing this.

Link to post

I'm new to unraid and I've waited for this RC release for AD to work correctly. 

 

I've joined TOWER to the domain but authentication on a share does not authenticate.

 

root@Tower:~# wbinfo -a domainuser1

Enter domainuser1's password:

plaintext password authentication failed

Might anyone have recommend steps to get AD working for RC1?

Link to post

I'm new to unraid and I've waited for this RC release for AD to work correctly. 

 

I've joined TOWER to the domain but authentication on a share does not authenticate.

 

root@Tower:~# wbinfo -a domainuser1

Enter domainuser1's password:

plaintext password authentication failed

Might anyone have recommend steps to get AD working for RC1?

 

After joining to AD domain for the first time, go back to Main page, Stop array and then Start.  Let me know if this solves the authentication problem.  Also, what version of windows server are you using in your domain?

Link to post

I'm new to unraid and I've waited for this RC release for AD to work correctly. 

 

I've joined TOWER to the domain but authentication on a share does not authenticate.

 

root@Tower:~# wbinfo -a domainuser1

Enter domainuser1's password:

plaintext password authentication failed

Might anyone have recommend steps to get AD working for RC1?

 

Actually, did you try entering password twice?  For example, here is a sample diaglog:

 

root@Test1:~# wbinfo -a tomm
Enter tomm's password:
plaintext password authentication failed
Could not authenticate user tomm with plaintext password
Enter tomm's password:
challenge/response password authentication succeeded
root@Test1:~#

 

This is a quirk of wbinfo.

Link to post

madburg is my Shimei.

 

Yeap, and for those who don't know, I spent a ton of time working this and proc issues with Tom, long time ago. And offered 2 cards on the house. Glad you retracked your prior as I decided to go spend the time with my daughter, instead of a pissing match. Im much better now and seems the same for you. I am by no means harrasing. Speaking my mind that is all. And some factuals, yes it can hurt, but i've been pained as well, and put alot into this product with all intentions it woul be nothing but a success. And please if someone posts "what little I know" you have no business on the technical end to even being. Tom and others know exactly were I am coming from and not blowing hot air. And no Tom did not spend 30mins compiling a new kernel. It was a figure of speech, that not enought was done. And to work with us to get this resolved (and stop the hibernation for gods sake). Im am finished with pleding, begging, Ive done all that in the past.

 

 

Link to post

 

The offending line is:

smartctl: sending ioctl 2285 to a partition!

 

This is probably a bug in one of your plugins.  It's possible it's been around for a while, but unreported, and the guy writing the driver got around to flagging this error.  I can try and dig up what ioctl 2285 (0x8ED) refers to, but bigger fish to fry at the moment.  It would help to isolate which plugin is causing this.

 

not a problem, i completely understand. i will remove the plugins until i can figure out which one is the cuprit.

 

thanks

Link to post

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.