unRAID Server Release 5.0-rc14 Available

[garycase]

So someone confirm what I need to do in order to boot and test RC14. My machine has 4GB of ram installed, no more, no less. I think the answer is nothing, but if I want, I can edit the file talked about earlier with the dollar sign in front of a php variable. Correct?

 

With your hardware config (4GB RAM)...yes, answer is technically nothing other than follow the upgrade instructions in 5.0-rc14 release notes.  You edit the file to include the "$" once unRAID boots from a console or telnet session.

 

In addition to the "$" mod, you can skip copying the syslinux.cfg file to the flash drive -- you don't need that 4GB parameter.

 

[moose]

@moose: I would suggest you listen to Limetech's advice on this, and not the above poster. Just follow the instructions in the release notes, and copy the three files. The instructions were written exactly like that for a very specific reason. Strange as it may seem, even machines with exactly 4GB of RAM boot differently depending on that option.

 

Yes, I followed Limetech's advice and copied all 3 files including the syslinux.cfg file.

 

post edit: - no worries Barzija 

[axeman]

SimpleFeatures bit the bullet. even though I have that oom setting to do it on boot. used to stock? powerdown and dropped memory to 3GB and picked the option at the top (without the 4GB limit).

 

so far, seems somewhat better than 12a; never tried 13.

[garycase]

@moose: I would suggest you listen to Limetech's advice on this, and not the above poster. Just follow the instructions in the release notes, and copy the three files. The instructions were written exactly like that for a very specific reason. Strange as it may seem, even machines with exactly 4GB of RAM boot differently depending on that option.

 

Yes, I followed Limetech's advice and copied all 3 files including the syslinux.cfg file.

 

Certainly doesn't hurt anything.  But also note Limetech's note in the first post that "... When the boot screen comes up you can hit a key and select the normal boot if your h/w platform doesn't have the "slow write" issue."    In other words, you can choose whether or not to actually use that parameter -- the syslinux.cfg file just made it the default.

 

There was a lot of discussion about whether this was actually required in the early pages of this thread.  Prostuff suggested simply moving the "menu default" line to one of the other options; Joe L suggested leaving off the limit; WeeboTech agreed with Prostuff's suggestion to just move the default option;  several suggested just eliminating it; Barzija even said "... I was against leaving that boot option and I pleaded with Limetech for one non-pae RC." and in a later post (#67) said "... it is a bad idea." to have that line included.  Tom is indeed looking in to a better way to resolve the issues for those that have them (see post #70).

 

Since you added the option, you should try booting both ways => it will default with the 4GB option;  or you can select the "normal" option on the initial boot screen (you'll need a display and keyboard connected).  If you don't have a keyboard/monitor connected, you can try it both ways by simply editing the syslinux.cfg file you copied and put the "menu default" line on the normal boot option.

 

[garycase]

The mem=nn[KMG] parameter is used to "Force usage of a specific amount of memory. Amount of memory to be used when the kernel is not able to see the whole system memory or for test."

 

Which is why it is a bad idea.

 

I gather you've changed your mind 

[jumperalex]

Seriously dude, do you ever even watch any movie you put on your server?

 

Even more imortant .. Do you even lift?  ;D

[dirtysanchez]

I don't know why you keep telling people that they don't need that option. Limetech made it the default for a good reason, to see how many of people's problems will disappear with it.  Seriously dude, do you ever even watch any movie you put on your server?

 

Maybe because a lot of us (probably even the vast majority of us) DON'T need it. I have 8GB in my server and no issues at all, even with it running a few plugins. I've read this whole thread and I understand YOUR situation and what you're trying to accomplish, but you might want to consider leaving the snotty little personal attacks out. It doesn't help your cause.

[Ice_Black]

[garycase]

I don't advocate either way.  I simply noted that there is a lot of discussion in this thread about whether or not the 4GB parameter is necessary.    Tom's choice was to make it the default, but also to note that you could select either way at boot -- but as quickly became evident that choice caused issues with systems with less than 4GB of installed RAM (as you noted in an earlier post).      The discussion throughout the thread also made it clear that this is not always a needed option.

 

The prudent choice is to simply try it both ways to see which works best for a specific system.  On my system (X7SPA-H-D525-O) the parameter is not needed, and in fact seems to impact performance negatively.    Without the 4GB parameter, I get 120MB/s transfers from the array; 7:33 parity checks; and excellent write speeds (~ 35MB/s).    With it, both the transfer speeds and the parity check are somewhat slower (I didn't actually run a full parity check that way, but the initial speed was notably slower).

 

[madburg]

Yes, but this goes back to retarded posts provoking people.

 

Tom made clear instructions, they should be followed unless you know why the new default option does not work for you. GaryCase is not JoeL, nor WeeboTEch, etc. and should reframe from posting every 2 f'in minutes with BS he picks up along the way. "I'm no Linux guy, but let me tell everyone with a question what to do" really?

 

This is not Final, Tom may change his mind and revert back the menu order. There was no harm done in trying it this way. I personally wish we got more changes in a rapid fashion.

 

Time for a Tom intervention by posting.

[garycase]

 

Best advice in the last few pages 

 

Chill pills go down easier with a nice glass of Merlot  :)

[madburg]

Without the 4GB parameter, I get 120MB/s transfers from the array; 7:33 parity checks; and excellent write speeds (~ 35MB/s).    With it, both the transfer speeds and the parity check are somewhat slower (I didn't actually run a full parity check that way, but the initial speed was notably slower).

 

What is "somewhat slower", you post spec's for one but not the other, useless post. No value.

[garycase]

Without the 4GB parameter, I get 120MB/s transfers from the array; 7:33 parity checks; and excellent write speeds (~ 35MB/s).    With it, both the transfer speeds and the parity check are somewhat slower (I didn't actually run a full parity check that way, but the initial speed was notably slower).

 

What is "somewhat slower", you post spec's for one but not the other, useless post. No value.

 

For the same 4GB file that copied at 120MB without the 4GB option, it copied at 95MB with the 4GB limit.  Parity check started out at about 130MB/s ... about 20MB/s slower than it does without the option.  As I noted, I didn't bother to run it to see how much difference it would make ... but clearly it would have taken longer than the 7:33 it does now.      I didn't include the details as the point was simply that it was slower.  Point was my system does not need the 4GB option ... nor do many others (as dirtysanchez noted above).

 

Not sure why you & Barzija are so hyper about simply suggesting that it makes sense to test a system both with AND without the 4GB option to determine whether a specific configuration needs it.    I'm agnostic about the option => but I DO think the prudent approach is to try it both ways.  It may or may not be true (as dirtysanchez indicated) that "... (probably even the vast majority of us) DON'T need it." ==> but it's certainly true that SOME don't.

 

[dirtysanchez]

Tom made clear instructions, they should be followed unless you know why the new default option does not work for you.

 

Absolutely, as long as one still has the option to use more than 4GB when it works in their particular situation, it's a fair solution.

 

This is not Final, Tom may change his mind and revert back the menu order. There was no harm done in trying it this way. I personally wish we got more changes in a rapid fashion.

 

+1 to that whole statement. Couldn't agree more.

[Joe L.]

This is not Final, Tom may change his mind and revert back the menu order. There was no harm done in trying it this way. I personally wish we got more changes in a rapid fashion.

 

Time for a Tom intervention by posting.

Tom did not consider what would happen if that added "mem=" directive was used on a system with less than 4Gig of RAM by "default".

(apparently his test systems all have at least that amount)

 

Once it was reported that those with less memory crashed when trying to access memory they did not have, he did make a comment here:

http://lime-technology.com/forum/index.php?topic=27874.msg246856;topicseen#msg246856

Obviously, he is feeling the pain.

 

The best advice right now, is do not use the "mem=" line if you do not have at least 4Gig of ram.

 

Joe L.

[madburg]

Yeah your 6 equally sized drives, with nothing going on, against what my config is and had going on.

 

Read the whole post => I noted that with all the other stuff you had going on it wasn't bad.  Any other activity on the system always causes a notable extension of the time;  and in your case that old 250GB drive has to be a major "drag" at the start ... plus you've also got to contend with the 2TB drives.    Given all that, it's not a bad time at all.    But the question was whether it was a good time for a 3TB parity drive ... and in that context it's not -- but there's good reason why it's slower.    BTW, the number of drives makes almost no difference in the time -- it's their relative sizes and speeds.

 

As a matter of interest, why do you keep that old 250GB drive in there??

 

" But the question was whether it was a good time for a 3TB parity drive  " that was not the question!

 

The number of drives do matter. You think all controllers and expanders are made equal, you think that 6 drives connected to onboard SATA ports is the same as 24 drives hanging off a SAS controller and expander, because all that matters is that the parity drive is X size?

 

I keep a 250GB drive (just recently removed (4) 160GB drive from unRAID) because the street resale is $2, to me its 250GB for temp stuff in a slot I have available, priceless. Unlike you I use what I build and not trying to beat some type of record. I am very aware of what healthy is, when I had (6) 2TB drives is was very different then what it is now. And through varies disk additions and removals in 2 years I know that last nights parity check was very good for my system, I didn't calm it crushed any record. I am more interested in seeing if anything shows itself when being pushed. Like the SAS messages logged.

 

 

 

 

[WeeboTech]

OK Guys, Can we put aside the merits of PAE vs NON PAE.

 

The truth is in the pudding.

A core issue is a performance problem on some motherboards with large amounts of ram.

Another being stability.

 

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

 

For years we've had a PAE kernel with no memory limit.  It might be worthwhile to try that first.

Then if time & desire or a performance problem is revealed try the option with the memory limit.

 

If you have less then 4GB, it should not matter, but according to some historical points I remember, it could.

 

``The kernel will accept any `mem=xx' parameter you give it, and if it turns out that you lied to it, it will crash horribly sooner or later.  The parameter indicates the highest addressable RAM address, so `mem=0x1000000' means you have 16MB of memory, for example.  For a 96MB machine this would be `mem=0x6000000'. If you tell Linux that it has more memory than it actually does have, bad things will happen: maybe not at once, but surely eventually.''

 

I don't know if this is the case any more.

 

Parity sync and generate speeds vary so widely between systems that you cannot always judge it as fact.  I think we need to consider our own systems and historical performance of them.

 

I'm sure there's a bottom line here which can be interpreted by the community.

I know in my systems (I've made many) If I were getting under 60MB/s in a parity generate or check, something was wrong.  But we each have different systems, configurations and layouts.

 

[madburg]

This is not Final, Tom may change his mind and revert back the menu order. There was no harm done in trying it this way. I personally wish we got more changes in a rapid fashion.

 

Time for a Tom intervention by posting.

Dont use the Default "mem=" line if you do not have at least 4Gig of ram.

 

Joe L.

 

Thanks Joe L., understood, it was a test, not all will work out well. The other boot option exists and was not removed so no foul, it should just be more prominently displayed by being in the OP. Not everyone is going to read through all of gray's posts. I feel sick personally (LOL just kidding) 

 

So can the one liner above be added to the OP (Tom's announcement of RC14), that should make things very clear for how to bring up RC14 as it currently stands. And then we don't need gary posting what to do.

 

[garycase]

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.

 

[tr0910]

She won't format?

 

Starting up my 2nd RC14 system (other one is fine) with a newly precleared disk in it resulting in the normal messaging.  But saying that "I want to do this" and pressing the "format" button results in the system starting the format process, but pressing refresh shows that it hasn't started formatting at all.  You can restart formatting again, but it doesn't seem to do anything if you hit refresh.  Main screen shows 6 disks and parity disk all being green balled and valid but there is a message that unformatted disks are present (disk7)

 

She's likely still loading unMenu and some addons like "powerdown now" and "screen".  otherwise she's stock....

Attach a syslog to your next post, otherwise, we have no clues either.

 

Of Course, here you go...

 

I ran a test on the drive and it says that it wasn't precleared.  May be my faulty memory.  I was sure it was precleared.  Preclearing again now...

 

failed test 1                                                                                                                                          
failed test 3 00238 00255 00255 00255 

[Nism0]

Since RC14 i have 90MB/s Read and 40MB/s write.

I have never had speeds like this with my Unraid server.

 

Thank you for a great update!!! 

[Thornwood]

sorry to bother but I seem to have a problem.

My cash drive dose not show up. and I mean at all. I made sure bios can see the drive. on 13 normally sdg now it is just gone. I cant even put it on another slot. I am running addons so I will try to reboot clean but even unmenu cant see the drive.

I have a Supermicro - X9SRA with (2) AOC-SASLP-MV8 and on 13 with same add ons it shows up just fine? I did add,

 

sed -i  " s/ show_disk / \$show_disk /" /usr/local/emhttp/plugins/indexer/Browse.php

 

in the go script

log attached

 

Thornwood

syslog.zip

[Thornwood]

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.

syslog.zip

[Joe L.]

sorry to bother but I seem to have a problem.

My cash drive dose not show up. and I mean at all. I made sure bios can see the drive. on 13 normally sdg now it is just gone. I cant even put it on another slot. I am running addons so I will try to reboot clean but even unmenu cant see the drive.

I have a Supermicro - X9SRA with (2) AOC-SASLP-MV8 and on 13 with same add ons it shows up just fine? I did add,

 

sed -i  " s/ show_disk / \$show_disk /" /usr/local/emhttp/plugins/indexer/Browse.php

 

in the go script

log attached

 

Thornwood

I would suspect your power supply before anything else.  Not likely to be release related unless you have less than 4Gig of RAM and copied the newer syslinux.cfg into place.

[tyrindor]

Around 30% slower parity checks on RC14 compared to RC13 with my two SAS2LP servers (even with the customized sync_window parameter). Seems like that newer kernel had some newer SAS2LP drivers that perform better.

 

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.