unRAID Server Release 5.0-rc14 Available


Recommended Posts

The power is not an issue I have a 800W single rail and I stager spin ups and as I stated Bios shows all drives. so does 13 see new log.

I am back on 13 and all drives show up so it might be that the 4 TB drives are a little slow to or something for unraid..... I really don't know but I do know hardware is rock solid all connections are good.

syslog_of_13.zip

Link to comment
  • Replies 203
  • Created
  • Last Reply

Top Posters In This Topic

The number of drives do matter.

 

More precisely, the bandwidth of the drive INTERFACES matter.  My parity checks did not vary significantly (more than a couple minutes) when I first tested the Atom board with 3 drives, and  then populated it with the 6 it supports.    Granted these are all on motherboard ports, so they have interfaces that support the full bandwidth of the drives.

 

Clearly if I used an interface card that could not provide full bandwidth to all the drives, then adding more drives would slow down the parity checks -- but NOT because of the number of drives ... only because of the bandwidth throttle that a card might cause.

 

If I wanted a system with 24 drives, I'd buy a card that supported full bandwidth to all of those drives, like a RocketRAID 2760A or Adaptec 72405.      I'd fully expect the parity checks on that system to be in the same range as I'm getting now with those cards.    But obviously if I connected them through a slower interface card and split the bandwidth further via expanders, the results would not be as good.

 

You can fully expect what you want, but that won't be the case. Pick either card, but the additional drives and you will see that you will not maintain the same results.

 

Your the guy who talks about what a Lamborghini can do versus a Ferrari, but you drive a Honda at the moment.

The Bugatti Veyron has 2 motors in one car, it should have double the performance? but it doesn't.

Link to comment

However, I had issues with RC13. 4 drives in one server were being read/wrote constantly when nothing was running/accessing them... and both arrays refused to stop. I know the latter issue was fixed in RC14 with downgrading the kernel, but I hope the other issue was too. Hopefully RC15 uses a newer kernel that doesn't have these issues, and allows my SAS2LP cards to run their best.

I suspect that a Linux kernel that fixes the issue identified in RC14 is likely to take much longer to arrive than the 5.0 final release.

Link to comment

OK I'm a little confused now. When I get home I will try this on my unRAID2 setup. It has 2GB of memory. Do I need to do anything special with this release, like not copying over the config file for it to work?

 

Will not copying over the config file get it to work with my unRAID1 that has 4GB of memory? Since it didn't work last night when I copied over all three files.

Link to comment

OK I'm a little confused now. When I get home I will try this on my unRAID2 setup. It has 2GB of memory. Do I need to do anything special with this release, like not copying over the config file for it to work?

 

Will not copying over the config file get it to work with my unRAID1 that has 4GB of memory? Since it didn't work last night when I copied over all three files.

Right, sorry about that, for your servers with less than 4GB of memory or less, don't copy over the 'syslinux.cfg' file.  I will correct this soon.

Link to comment

OK I'm a little confused now. When I get home I will try this on my unRAID2 setup. It has 2GB of memory. Do I need to do anything special with this release, like not copying over the config file for it to work?

 

Will not copying over the config file get it to work with my unRAID1 that has 4GB of memory? Since it didn't work last night when I copied over all three files.

You can skip copying over the syslinux.cfg file or

you can edit it and move the menu default line to the entry without the mem= parameter.

 

I'm unable to access my machine or I would post a more comprehensive capture.

Link to comment

ok now even worse. I think it has to do with my 4tb drives...... this time my cash drive appeared but no party drive.

sorry going back to rc13.

 

log attached.

In the attached syslog it looks like all 10 array drives are there, but no 11th drive (your cache drive?).  What port is this drive attached to?  Does it appear in your bios when the system starts up?

Link to comment

2 of my servers had only 2gb of memory.  They started with rc14 but unMenu went wild claiming the array wasn't started and no drives were installed.  Yet I could access them, and the unRaid screen showed no problems.  It was only unMenu that was in trouble.  I edited the syslinux.cfg file to set the default from 4 gb unRaid OS to standard unRaid OS and the problems have gone away. 

 

It was in this state that I complained about the inability for format a precleared drive.  Perhaps it scrambled it, as I am now preclearing it again.

Link to comment

2 of my servers had only 2gb of memory.  They started with rc14 but unMenu went wild claiming the array wasn't started and no drives were installed.  Yet I could access them, and the unRaid screen showed no problems.  It was only unMenu that was in trouble.  I edited the syslinux.cfg file to set the default from 4 gb unRaid OS to standard unRaid OS and the problems have gone away. 

 

It was in this state that I complained about the inability for format a precleared drive.  Perhaps it scrambled it, as I am now preclearing it again.

 

Just for fun, I cancelled the preclear then I rebooted without the 4gb limitation.  To see would happen, I had it retry the format.  Now it worked without a problem.  No preclear necessary.  Under the 4 gb limitation, preclear_disk.sh reported that the drive wasn't precleared. 

 

That 4gb limitation being the default will be a problem for those running less than 4gb.

Link to comment

ok now even worse. I think it has to do with my 4tb drives...... this time my cash drive appeared but no party drive.

sorry going back to rc13.

 

log attached.

In the attached syslog it looks like all 10 array drives are there, but no 11th drive (your cache drive?).  What port is this drive attached to?  Does it appear in your bios when the system starts up?

Yes it shows up in bios. now the out of my 11 drives two are Seagate 4tb drives and in Version 14 I loose one of those randomly eather the cash drive or my paraty drive.... I don't have enough money to by another to see of it happens with more 4tb drives but all the reboots show all drives in bios, it is just something to do with version 14..... I say this because version 13 or less seems fine with them.

Link to comment

Seems that many people here are obsessed with parity check speeds.

What's important to me though are the reading and writing speeds to the disks.

 

It would be helpful for people to post the results of stability and performance based on their findings on the most appropriate boot selection.

 

Maybe I can help make things a little more speciffic:  I am attaching to this post a small script, which writes a ~2GB file to all mounted disks simultaneously, and times the result.  Then it reads all those files simultaneously and times that too. (Then it cleans up after itself.).  When I run that script on my machine with RC14, the times are signifficantly better with the "mem=" option than without it.  Note: the times displayed are the seconds it takes to finish, so lower-is-better.

 

Anyone who wants to test the difference with the boot options is welcome to run this script, and report their findings here.

 

Barzija , Start a new thread with your script so we can discuss it in more detail.

For example, The script needs to drop the cache before any tests to insure the buffer cache does not come into play and skew results.

 

Yes, I'll start a new thread. Just not right now please.

 

This version here it's just a quick script to show the differences between the two boot options. And for this purpose, not droping the caches makes the problems with large amounts of RAM even more evident: the system is desperately trying to deal with the mess it's made of the highmem, and stalls to a halt.  Real-life situation, rather then a scientiffic benchmark. :)

 

Edit: Updated version atached.

Output much more informative.

 

Does this need to be in an announcement thread?

it's not strictly related to the release, it's related to any release using PAE.

 

Does Tom need to read every point back and forth on this, or should we discuss it in a thread people are interested to sign up for, then present the final findings to Tom?

 

In addition, it looks like the script may write to /mnt/user which is ram, is this intended?

What happens if they only have 1GB of ram?

 

Joe L's original unRAID system has 512M.

Link to comment

In addition, it looks like the script may write to /mnt/user which is ram, is this intended?

It will write to /mnt/user, and it will use up the RAM, making the subsequent tests less meaningful

What happens if they only have 1GB of ram?

 

Joe L's original unRAID system has 512M.

I did not try the script on the older server, but did check:

root@Tower2:~# free -l

            total      used      free    shared    buffers    cached

Mem:        505932    453244      52688          0      98304    239820

Low:        505932    453244      52688

High:            0          0          0

-/+ buffers/cache:    115120    390812

Swap:            0          0          0

Every other time I've run the server out of memory it would invoke the kernel's OOM killer routine. 

(basically unRAID will crash, typically killing emhttp, smbd, and eventually ... telnet sessions.)

 

 

Link to comment

The number of drives do matter.

 

More precisely, the bandwidth of the drive INTERFACES matter.  My parity checks did not vary significantly (more than a couple minutes) when I first tested the Atom board with 3 drives, and  then populated it with the 6 it supports.    Granted these are all on motherboard ports, so they have interfaces that support the full bandwidth of the drives.

 

Clearly if I used an interface card that could not provide full bandwidth to all the drives, then adding more drives would slow down the parity checks -- but NOT because of the number of drives ... only because of the bandwidth throttle that a card might cause.

 

If I wanted a system with 24 drives, I'd buy a card that supported full bandwidth to all of those drives, like a RocketRAID 2760A or Adaptec 72405.      I'd fully expect the parity checks on that system to be in the same range as I'm getting now with those cards.    But obviously if I connected them through a slower interface card and split the bandwidth further via expanders, the results would not be as good.

 

You can fully expect what you want, but that won't be the case. Pick either card, but the additional drives and you will see that you will not maintain the same results.

 

Your the guy who talks about what a Lamborghini can do versus a Ferrari, but you drive a Honda at the moment.

The Bugatti Veyron has 2 motors in one car, it should have double the performance? but it doesn't.

 

 

Sorry, I feel I have to step in here. The Veyron does not have two engines. It has two Volkswagen V8 engines that are fused together to form a single W16 engine.  ;D

Link to comment

Let's not get into the transmission on that bad boy  :o, what a work of Art.

I can get 10 exotic cars for the price of that one. But no way to fuse them together to get 10000hp and go 1600mph.  :'(

 

 

My car cost only 2.2% of the price Veyron yet has a top speed only 50MPH slower. It's that last 50MPH between 200MPH and 250MPH that the costs go up exponentially.

Link to comment

Tom any idea what these SAS entries mean?

 

Jun 13 04:03:48 PNTower kernel: sd 0:0:10:0: attempting task abort! scmd(f2545240)
Jun 13 04:03:48 PNTower kernel: sd 0:0:10:0: [sdl] CDB: cdb[0]=0x2a: 2a 00 03 eb a4 20 00 04 00 00
Jun 13 04:03:48 PNTower kernel: scsi target0:0:10: handle(0x0014), sas_address(0x5001517e85bfcfe5), phy(5)
Jun 13 04:03:48 PNTower kernel: scsi target0:0:10: enclosure_logical_id(0x5001517e85bfcfff), slot(5)
Jun 13 04:03:48 PNTower kernel: sd 0:0:10:0: task abort: SUCCESS scmd(f2545240)
Jun 13 04:03:48 PNTower kernel: sd 0:0:10:0: attempting task abort! scmd(e5370f00)
Jun 13 04:03:48 PNTower kernel: sd 0:0:10:0: [sdl] CDB: cdb[0]=0x2a: 2a 00 03 eb a8 20 00 04 00 00
Jun 13 04:03:48 PNTower kernel: scsi target0:0:10: handle(0x0014), sas_address(0x5001517e85bfcfe5), phy(5)
Jun 13 04:03:48 PNTower kernel: scsi target0:0:10: enclosure_logical_id(0x5001517e85bfcfff), slot(5)
Jun 13 04:03:48 PNTower kernel: sd 0:0:10:0: task abort: SUCCESS scmd(e5370f00)
Jun 13 04:03:48 PNTower kernel: sd 0:0:10:0: attempting task abort! scmd(f1d69b40)
Jun 13 04:03:48 PNTower kernel: sd 0:0:10:0: [sdl] CDB: cdb[0]=0x2a: 2a 00 03 eb ac 20 00 04 00 00
Jun 13 04:03:48 PNTower kernel: scsi target0:0:10: handle(0x0014), sas_address(0x5001517e85bfcfe5), phy(5)
Jun 13 04:03:48 PNTower kernel: scsi target0:0:10: enclosure_logical_id(0x5001517e85bfcfff), slot(5)
Jun 13 04:03:48 PNTower kernel: sd 0:0:10:0: task abort: SUCCESS scmd(f1d69b40)
Jun 13 04:03:48 PNTower kernel: sd 0:0:10:0: attempting task abort! scmd(f5c47780)
Jun 13 04:03:48 PNTower kernel: sd 0:0:10:0: [sdl] CDB: cdb[0]=0x2a: 2a 00 03 eb b0 20 00 04 00 00
Jun 13 04:03:48 PNTower kernel: scsi target0:0:10: handle(0x0014), sas_address(0x5001517e85bfcfe5), phy(5)
Jun 13 04:03:48 PNTower kernel: scsi target0:0:10: enclosure_logical_id(0x5001517e85bfcfff), slot(5)
Jun 13 04:03:48 PNTower kernel: sd 0:0:10:0: task abort: SUCCESS scmd(f5c47780)
Jun 13 04:03:48 PNTower kernel: sd 0:0:10:0: attempting task abort! scmd(f5c47300)
Jun 13 04:03:48 PNTower kernel: sd 0:0:10:0: [sdl] CDB: cdb[0]=0x2a: 2a 00 03 eb b4 20 00 01 b8 00
Jun 13 04:03:48 PNTower kernel: scsi target0:0:10: handle(0x0014), sas_address(0x5001517e85bfcfe5), phy(5)
Jun 13 04:03:48 PNTower kernel: scsi target0:0:10: enclosure_logical_id(0x5001517e85bfcfff), slot(5)
Jun 13 04:03:48 PNTower kernel: sd 0:0:10:0: task abort: SUCCESS scmd(f5c47300)
Jun 13 04:03:48 PNTower kernel: sd 0:0:10:0: attempting task abort! scmd(f5c47480)
Jun 13 04:03:48 PNTower kernel: sd 0:0:10:0: [sdl] CDB: cdb[0]=0x2a: 2a 00 00 00 a7 40 00 00 70 00
Jun 13 04:03:48 PNTower kernel: scsi target0:0:10: handle(0x0014), sas_address(0x5001517e85bfcfe5), phy(5)
Jun 13 04:03:48 PNTower kernel: scsi target0:0:10: enclosure_logical_id(0x5001517e85bfcfff), slot(5)
Jun 13 04:03:48 PNTower kernel: sd 0:0:10:0: task abort: SUCCESS scmd(f5c47480)

 

You may have missed this post, Syslog from time parity check started to these events: http://lime-technology.com/forum/index.php?topic=27874.msg247029#msg247029

Link to comment

I'm running 2GB RAM on my box so I'm thinking of skipping this RC and going from 13-15.  I know it's an easy change to get 14 working, but judging from the other post in Announcements, a new RC might be out fairly soon.

 

Quick question though - if I'm running absolutely stock unRAID, 10 data drives + parity and cache (all WD Greens, mixture of 1 & 2 TB) storing DVD backups, do I need more than 2GB of RAM?  It seemed OK when I first built my 3 drive system, but it dawned on me when Tom didn't consider  <4GB systems for this RC that maybe the base configuration has gone up.

 

Would I benefit?  I've had a couple of crashes in the past where the system's just dropped off the network and I've had to hold the power button in (normally after writing lots of data).  Could they be insufficient memory related? (obviously don't expect an answer based on so little information, just throwing ideas).

Link to comment

I'm running 2GB RAM on my box so I'm thinking of skipping this RC and going from 13-15.  I know it's an easy change to get 14 working, but judging from the other post in Announcements, a new RC might be out fairly soon.

 

Quick question though - if I'm running absolutely stock unRAID, 10 data drives + parity and cache (all WD Greens, mixture of 1 & 2 TB) storing DVD backups, do I need more than 2GB of RAM?  It seemed OK when I first built my 3 drive system, but it dawned on me when Tom didn't consider  <4GB systems for this RC that maybe the base configuration has gone up.

 

Would I benefit?  I've had a couple of crashes in the past where the system's just dropped off the network and I've had to hold the power button in (normally after writing lots of data).  Could they be insufficient memory related? (obviously don't expect an answer based on so little information, just throwing ideas).

 

 

Stock unRAID does not require more then 512MB of ram. Your usage pattern could possibly benefit from more ram as more data would be cached in the kernel buffers.  It all depends on how much you read/write, how fast you need to write and if you run other applications.  I would say if you have 2GB now, you are fine.  It wasn't that Tom didn't consider systems with less then 4GB.  It's popular to put allot of ram into the machines nowadays. The 4GB memory limit window was purely a possible workaround for the slow write issue.  Ramifications of the default were not considered enough, but that's about it.

Link to comment

Let's not get into the transmission on that bad boy  :o, what a work of Art.

I can get 10 exotic cars for the price of that one. But no way to fuse them together to get 10000hp and go 1600mph.  :'(

 

 

My car cost only 2.2% of the price Veyron yet has a top speed only 50MPH slower. It's that last 50MPH between 200MPH and 250MPH that the costs go up exponentially.

 

It will also get there 2.2% as fast

/off topic

Sent from my SAMSUNG-SGH-I727 using Tapatalk 4 Beta

 

Link to comment

Tom,

 

I've wrapped up my testing of RC14, using my 'Current' build in my signature line.  I tested with both mem=4095M and without, and ran full parity checks, starts/stops/starts/stops and powerdowns through GUI using unRAID's stock script, copying 100's of gigabytes of data to the array, and watching Blu-Ray ISO's on the array. 

 

I did not add/upgrade/remove/format any drives, so I can't report on those capabilities.

 

No issues to report, great job!  The md_sync_window fixes are still working perfectly for me on RC14, just as they did on RC12a (I skipped RC13, sorry).

 

Interestingly, even though the mem=4095M parity check appeared slower to my eyes (reported speeds seemed 5-10% lower while processing), by the stopwatch both parity checks completed within a minute of each other, regardless of the mem=4095M setting.  I guess the only way to test is to run a full parity, as eyeballing it just didn't cut it. 

 

Thank you,

-Paul

Link to comment

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.