unRAID Server Release 5.0-rc10 Available


limetech

Recommended Posts

how much memory in yor system?

 

8GB.

 

I just updated my 2nd server to 10 and the speed issues are still there. 63MB/s after 2% into parity sync, estimated 13 hours to finish. My other server, which has far more drives, took 26 hours to finish last time. If I invalidated parity, and then rebuilt it from scratch, i'd get about 100-110MB/s... so it's definitely not a bandwidth issue... When I upgrade to 4TB, it's just going to get worse. It's already too long. :(

 

It's sad because I spent over a grand building these 2 servers (not including drives), just so I could make parity syncs faster... and then a month later unRAID updated which slowed both systems down to speeds below my old servers. Seems like these speed issues are going to make it into 5.0 final because not enough people seem to have them.

 

Read this thread from this point on:

 

    http://lime-technology.com/forum/index.php?topic=22675.msg220309#msg220309

 

Apparently, some hardware has issues with 32bit OS's and large memory.  (32 bit OS can only directly access 4GB of memory.)

Link to comment
  • Replies 284
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

how much memory in yor system?

 

8GB.

 

I just updated my 2nd server to 10 and the speed issues are still there. 63MB/s after 2% into parity sync, estimated 13 hours to finish. My other server, which has far more drives, took 26 hours to finish last time. If I invalidated parity, and then rebuilt it from scratch, i'd get about 100-110MB/s... so it's definitely not a bandwidth issue... When I upgrade to 4TB, it's just going to get worse. It's already too long. :(

 

It's sad because I spent over a grand building these 2 servers (not including drives), just so I could make parity syncs faster... and then a month later unRAID updated which slowed both systems down to speeds below my old servers. Seems like these speed issues are going to make it into 5.0 final because not enough people seem to have them.

 

Read this thread from this point on:

 

    http://lime-technology.com/forum/index.php?topic=22675.msg220309#msg220309

 

Apparently, some hardware has issues with 32bit OS's and large memory.  (32 bit OS can only directly access 4GB of memory.)

 

Thank you for this, i'll give it a go.

 

Edit: Did not work for me (at least with parity sync speeds). I'll have to check write speed later, but i'm more concerned about 12-24 hour parity syncs.

Link to comment

I'm curious about parity check speeds, and what things people can do to improve them.  I have always had parity check speeds that some here have called "unacceptable," in the range of nearly 12 hours.  I got a speed of 10 hours this week with this latest rc. It is still not what I am hoping for - I'd really like to see 6 hrs for my 3 TB 7200 rpm seagate.  My hardware is relatively new, the processor should not be a bottleneck, I have 4 gb of ram, my parity drive uses a m/b sata port, I just can't understand why my parity check should be so long.

 

I apologize for interjecting this in this thread, but if someone could point me to a discussion of this topic, I'd really appreciate it.  I did notice that at the end of this weeks' check I was getting more that 100 MB/s - dont remember the number.  But 160 MB/s would be great. 

Link to comment

Upgraded to 5.0rc10 from 4.7.

Everything looks great aside from my write speeds now being abysmal(4-5MB/s avg, spikes to 20MB/s), Reads are 80-90MB/s.

Onboard Realtek 8112L

 

Just a quick peek at your syslog, but nothing jumps out as a problem.  I think the same advice from a couple of posts above yours applies, add the mem=4095M parameter.

Link to comment

Upgraded to 5.0rc10 from 4.7.

Everything looks great aside from my write speeds now being abysmal(4-5MB/s avg, spikes to 20MB/s), Reads are 80-90MB/s.

Onboard Realtek 8112L

 

Just a quick peek at your syslog, but nothing jumps out as a problem.  I think the same advice from a couple of posts above yours applies, add the mem=4095M parameter.

 

Thanks, added mem=4095M and rebooting, will post back when I see results !

Link to comment

In rc.S:

# tmm - here's a hack: loop until /dev/disk/by-label/UNRAID is present
# this serves to synchronize this script with USB subsystem
while [ ! -e /dev/disk/by-label/UNRAID ]; do
  echo "waiting for USB subsystem"
  sleep 1
done

 

Do you really need to do that?  What, wait here forever?

 

You could wait a bit -- if you absolutely must -- but then let the machine finish booting up.

 

If shit has happened we need access to the conssole to see/fix what's wrong.

 

(In have a good idea what could be wrong in this particular scenario, but that's beside the point)

 

You don't like my hack?  :D

 

I guess I was thinking, if the flash doesn't mount there's nothing much to do and if someone actually sees this I would get an email and could investigate what was going on.

Link to comment

Upgraded to 5.0rc10 from 4.7.

Everything looks great aside from my write speeds now being abysmal(4-5MB/s avg, spikes to 20MB/s), Reads are 80-90MB/s.

Onboard Realtek 8112L

 

Just a quick peek at your syslog, but nothing jumps out as a problem.  I think the same advice from a couple of posts above yours applies, add the mem=4095M parameter.

 

Thanks, added mem=4095M and rebooting, will post back when I see results !

 

Hey, back from my reboot, just to confirm, mem=4095M is to be added to syslinux.cfg( I placed as last line ) and then reboot the server and all should be well ?

I am still getting the same abysmal write speeds, however it appears that its still using 8gb of ram:

 

Memory Info

 

(from /usr/bin/free)

 

            total      used      free    shared    buffers    cached

Mem:      8197192    733800    7463392          0      4420    654100

-/+ buffers/cache:      75280    8121912

Swap:            0          0          0

 

 

Thanks for your time.

Link to comment
I apologize for interjecting this in this thread, but if someone could point me to a discussion of this topic, I'd really appreciate it.  I did notice that at the end of this weeks' check I was getting more that 100 MB/s - dont remember the number.  But 160 MB/s would be great. 

 

you might need to adjust your expectations a little bit.  with three 2TB drives on all MB sata, 4GB and a dual core AMD 7750 I am seeing 93mb/s (unraid reported) based on a completion time of 5:5x.

 

Do the math for 3TB, even with the jump from 5400 to 7200 drives 7 hour is the best you can hope for assuming you scale up from my 93mb/s to 123mb/s.  That is based on the 33% increase from 5400 to 7200, which is unlikely to happen given everything else involved in a parity check.  Your 100mb/s is really not too bad.

 

The fact is there is a lot of i/o going on when reading multiple drives all at the same time over the bus and then having to calculate pairty and then compare it.  They may all seem like trivially easy things, but summed together, each with just a little latency added in, and suddenly getting about ~75-80% of platter read speed is not too shabby.

Link to comment

Upgraded to 5.0rc10 from 4.7.

Everything looks great aside from my write speeds now being abysmal(4-5MB/s avg, spikes to 20MB/s), Reads are 80-90MB/s.

Onboard Realtek 8112L

 

Just a quick peek at your syslog, but nothing jumps out as a problem.  I think the same advice from a couple of posts above yours applies, add the mem=4095M parameter.

 

Thanks, added mem=4095M and rebooting, will post back when I see results !

 

Hey, back from my reboot, just to confirm, mem=4095M is to be added to syslinux.cfg( I placed as last line ) and then reboot the server and all should be well ?

I am still getting the same abysmal write speeds, however it appears that its still using 8gb of ram:

 

Memory Info

 

(from /usr/bin/free)

 

            total      used      free    shared    buffers    cached

Mem:      8197192    733800    7463392          0      4420    654100

-/+ buffers/cache:      75280    8121912

Swap:            0          0          0

 

 

Thanks for your time.

 

I believe I found the proper syntax to add, trying again !

 

edit:

label unRAID OS (MAX 4GB RAM)

  kernel bzimage

  append  mem=4095M initrd=bzroot

being what I think is needed

Link to comment

Upgraded to 5.0rc10 from 4.7.

Everything looks great aside from my write speeds now being abysmal(4-5MB/s avg, spikes to 20MB/s), Reads are 80-90MB/s.

Onboard Realtek 8112L

 

Just a quick peek at your syslog, but nothing jumps out as a problem.  I think the same advice from a couple of posts above yours applies, add the mem=4095M parameter.

 

Thanks, added mem=4095M and rebooting, will post back when I see results !

 

Hey, back from my reboot, just to confirm, mem=4095M is to be added to syslinux.cfg( I placed as last line ) and then reboot the server and all should be well ?

I am still getting the same abysmal write speeds, however it appears that its still using 8gb of ram:

 

Memory Info

 

(from /usr/bin/free)

 

            total      used      free    shared    buffers    cached

Mem:      8197192    733800    7463392          0      4420    654100

-/+ buffers/cache:      75280    8121912

Swap:            0          0          0

 

 

Thanks for your time.

If you really did add it as the last line in the file then that would be wrong.  It should be something like this
default menu.c32
menu title Lime Technology LLC
prompt 0
timeout 50
label unRAID OS
  menu default
  kernel bzimage
  append initrd=bzroot
label unRAID OS (MAX 4GB RAM)
  kernel bzimage
  append  mem=4095M initrd=bzroot    <===== this is where it goes
label Memtest86+
  kernel memtest

from StevenD's post.

Link to comment

Upgraded to 5.0rc10 from 4.7.

Everything looks great aside from my write speeds now being abysmal(4-5MB/s avg, spikes to 20MB/s), Reads are 80-90MB/s.

Onboard Realtek 8112L

 

Just a quick peek at your syslog, but nothing jumps out as a problem.  I think the same advice from a couple of posts above yours applies, add the mem=4095M parameter.

 

Thanks, added mem=4095M and rebooting, will post back when I see results !

 

Hey, back from my reboot, just to confirm, mem=4095M is to be added to syslinux.cfg( I placed as last line ) and then reboot the server and all should be well ?

I am still getting the same abysmal write speeds, however it appears that its still using 8gb of ram:

 

Memory Info

 

(from /usr/bin/free)

 

            total      used      free    shared    buffers    cached

Mem:      8197192    733800    7463392          0      4420    654100

-/+ buffers/cache:      75280    8121912

Swap:            0          0          0

 

 

Thanks for your time.

If you really did add it as the last line in the file then that would be wrong.  It should be something like this
default menu.c32
menu title Lime Technology LLC
prompt 0
timeout 50
label unRAID OS
  menu default
  kernel bzimage
  append initrd=bzroot
label unRAID OS (MAX 4GB RAM)
  kernel bzimage
  append  mem=4095M initrd=bzroot    <===== this is where it goes
label Memtest86+
  kernel memtest

from StevenD's post.

 

I edited my post right before you replied, I had found the post from StevenD, ty :)

So, speeds are oddly better ? now instead of spiking to 20MB/s it is spiking to 45MB/s, however, it's avg is still 4-5MB/s

If it makes any difference, it appears to hang a tad when I first attempt to transfer(sits on calculating space for 5-15 seconds before it starts to send)

I will also mention that despite adding the proper stuff to the config file, I am still showing as having 8gb of ram under mem info.

Link to comment

are you actually selecting the correct option during boot?  Because as written the default option will NOT include mem=4095

I changed syslinux.cfg to:

 

default menu.c32

menu title Lime Technology LLC

prompt 0

timeout 50

label unRAID OS (MAX 4GB RAM)

  menu default

  kernel bzimage

  append  mem=4095M initrd=bzroot

label Memtest86+

  kernel memtest

 

 

It is now showing :

 

(from /usr/bin/free)

 

            total      used      free    shared    buffers    cached

Mem:      3585480    3472720    112760          0      43784    3319664

-/+ buffers/cache:    109272    3476208

Swap:            0          0          0

 

So, it appears that it worked, however, I am still having the same crappy 4-5MB/s write speeds.

 

Thanks all for your time :)

Link to comment

Thanks for that, Alex, I had not thought about it that way.  It makes sense. 

 

you might need to adjust your expectations a little bit.  with three 2TB drives on all MB sata, 4GB and a dual core AMD 7750 I am seeing 93mb/s (unraid reported) based on a completion time of 5:5x.

 

Do the math for 3TB, even with the jump from 5400 to 7200 drives 7 hour is the best you can hope for assuming you scale up from my 93mb/s to 123mb/s.  That is based on the 33% increase from 5400 to 7200, which is unlikely to happen given everything else involved in a parity check.  Your 100mb/s is really not too bad.

 

The fact is there is a lot of i/o going on when reading multiple drives all at the same time over the bus and then having to calculate pairty and then compare it.  They may all seem like trivially easy things, but summed together, each with just a little latency added in, and suddenly getting about ~75-80% of platter read speed is not too shabby.

Link to comment

I apologize for interjecting this in this thread, but if someone could point me to a discussion of this topic, I'd really appreciate it.  I did notice that at the end of this weeks' check I was getting more that 100 MB/s - dont remember the number.  But 160 MB/s would be great. 

 

you might need to adjust your expectations a little bit.  with three 2TB drives on all MB sata, 4GB and a dual core AMD 7750 I am seeing 93mb/s (unraid reported) based on a completion time of 5:5x.

 

Do the math for 3TB, even with the jump from 5400 to 7200 drives 7 hour is the best you can hope for assuming you scale up from my 93mb/s to 123mb/s.  That is based on the 33% increase from 5400 to 7200, which is unlikely to happen given everything else involved in a parity check.  Your 100mb/s is really not too bad.

 

The fact is there is a lot of i/o going on when reading multiple drives all at the same time over the bus and then having to calculate pairty and then compare it.  They may all seem like trivially easy things, but summed together, each with just a little latency added in, and suddenly getting about ~75-80% of platter read speed is not too shabby.

 

I agree very much with what was said above.

 

I would also like to add two other factors that affect the speed.  One is that drives are rotational (WOW, really!?!), and that means the access to them is not linear, at all, especially when accessing multiple drives, even if they are the same rotational speed.  When you try to read a sector, you have to wait for it to rotate around to you, and if you happened to just miss it, you will need to wait for a complete rotation.  With multiple drives, this is very hard to forecast.  Only a small delay elsewhere, may cause additional rotations, resulting in significant speed variance.

 

In addition, at any given moment the speed of a parity check cannot be faster than the current slowest drive, AND at what point on that drive it is currently reading.  You start reading a drive in its fast tracks, but as you move towards the end of the drive, it gets slower and slower.  So a parity check involving 2 fast 2TB drives and a slow 300GB drive is going to be very slow at the 250GB point, slowest of all at the 299GB point.  It will probably be at its fastest at the 301GB point, then slow some as it approaches the 2TB end point.  The 301GB point may be faster than the 1GB point because it cannot go faster than the slowest drive (at its fastest!) at the 1GB point (depends on the drives of course).

 

Edit:  Just to add that, because it's the slowest drives that control the speed, you cannot speed up a parity check by adding a faster drive, but you CAN speed it up by removing a slow drive.

Link to comment

Upgraded to 5.0rc10 from 4.7.

Everything looks great aside from my write speeds now being abysmal(4-5MB/s avg, spikes to 20MB/s), Reads are 80-90MB/s.

Onboard Realtek 8112L

 

Read this thread from this point on:

 

    http://lime-technology.com/forum/index.php?topic=22675.msg220309#msg220309

 

Apparently, some hardware has issues with 32bit OS's and large memory.  (32 bit OS can only directly access 4GB of memory.)

Link to comment

 

 

A couple of people have mentioned but it has not been picked up as far as I can see....

 

Shares/nfs keep dropping on 10. I notice it from my xbmc, everything plays fine (a movie). When it has finished and go back the menu to play something else... it doesnt connect. I have to reboot xbmc.

My shares are mainly nfs with some smb.

 

I thought that it was an xbmc problem but just noticed it on a win8 machine that is saving a torrent (legal obviously!) onto an smb directory - error after a while about cant find destination.

 

Will roll back to 8a for more tests.

 

Tony

Link to comment

I'm curious about parity check speeds, and what things people can do to improve them.  I have always had parity check speeds that some here have called "unacceptable," in the range of nearly 12 hours.  I got a speed of 10 hours this week with this latest rc. It is still not what I am hoping for - I'd really like to see 6 hrs for my 3 TB 7200 rpm seagate.  My hardware is relatively new, the processor should not be a bottleneck, I have 4 gb of ram, my parity drive uses a m/b sata port, I just can't understand why my parity check should be so long.

 

I apologize for interjecting this in this thread, but if someone could point me to a discussion of this topic, I'd really appreciate it.  I did notice that at the end of this weeks' check I was getting more that 100 MB/s - dont remember the number.  But 160 MB/s would be great.

 

I don't think anyone gets 160MB/s parity checks unless their using SSDs for everything. 100MB/s is very acceptable, i'm still sitting at 60MB/s on hardware that should be getting 100+. My parity checks are between 16-24 hours on anything after beta12a, i've reported it so many times trying to get it fixed that i've given up on the issue. I would kill for 100MB/s again...

 

Upgraded to 5.0rc10 from 4.7.

Everything looks great aside from my write speeds now being abysmal(4-5MB/s avg, spikes to 20MB/s), Reads are 80-90MB/s.

Onboard Realtek 8112L

 

Just a quick peek at your syslog, but nothing jumps out as a problem.  I think the same advice from a couple of posts above yours applies, add the mem=4095M parameter.

 

Thanks, added mem=4095M and rebooting, will post back when I see results !

 

Hey, back from my reboot, just to confirm, mem=4095M is to be added to syslinux.cfg( I placed as last line ) and then reboot the server and all should be well ?

I am still getting the same abysmal write speeds, however it appears that its still using 8gb of ram:

 

Memory Info

 

(from /usr/bin/free)

 

            total      used      free    shared    buffers    cached

Mem:      8197192    733800    7463392          0      4420    654100

-/+ buffers/cache:      75280    8121912

Swap:            0          0          0

 

 

Thanks for your time.

If you really did add it as the last line in the file then that would be wrong.  It should be something like this
default menu.c32
menu title Lime Technology LLC
prompt 0
timeout 50
label unRAID OS
  menu default
  kernel bzimage
  append initrd=bzroot
label unRAID OS (MAX 4GB RAM)
  kernel bzimage
  append  mem=4095M initrd=bzroot    <===== this is where it goes
label Memtest86+
  kernel memtest

from StevenD's post.

 

That config would require you to select unRAID OS (MAX 4GB RAM) when unRAID boots. It would be better just to change "  append initrd=bzroot" to "  append mem=4095M initrd=bzroot", especially if you are one of those people that don't have a monitor/keyboard attached to your server. Correct me if i'm wrong, this is what I use.

 

default menu.c32

menu title Lime Technology LLC

prompt 0

timeout 50

label unRAID OS

  menu default

  kernel bzimage

  append  mem=4095M initrd=bzroot

label Memtest86+

  kernel memtest

 

Link to comment

 

 

A couple of people have mentioned but it has not been picked up as far as I can see....

 

Shares/nfs keep dropping on 10. I notice it from my xbmc, everything plays fine (a movie). When it has finished and go back the menu to play something else... it doesnt connect. I have to reboot xbmc.

My shares are mainly nfs with some smb.

 

I thought that it was an xbmc problem but just noticed it on a win8 machine that is saving a torrent (legal obviously!) onto an smb directory - error after a while about cant find destination.

 

Will roll back to 8a for more tests.

 

Tony

 

You need to attach a syslog which encompasses the period where the problem occurred  so that some experts can have a look at it.  You should include as much detail as possible about your system including the hardware that you are using. 

Link to comment

I'm curious about parity check speeds, and what things people can do to improve them.  I have always had parity check speeds that some here have called "unacceptable," in the range of nearly 12 hours.  I got a speed of 10 hours this week with this latest rc. It is still not what I am hoping for - I'd really like to see 6 hrs for my 3 TB 7200 rpm seagate.  My hardware is relatively new, the processor should not be a bottleneck, I have 4 gb of ram, my parity drive uses a m/b sata port, I just can't understand why my parity check should be so long.

 

I apologize for interjecting this in this thread, but if someone could point me to a discussion of this topic, I'd really appreciate it.  I did notice that at the end of this weeks' check I was getting more that 100 MB/s - dont remember the number.  But 160 MB/s would be great.

What other 3TB drives do you have and how are they connected?  For parity checking the speed will be determined by the slowest components in the chain, not just by the speed of the parity drive, since all drives are being read at the same time during checking.

Link to comment

Upgraded to 5.0rc10 from 4.7.

Everything looks great aside from my write speeds now being abysmal(4-5MB/s avg, spikes to 20MB/s), Reads are 80-90MB/s.

Onboard Realtek 8112L

 

Just a quick peek at your syslog, but nothing jumps out as a problem.  I think the same advice from a couple of posts above yours applies, add the mem=4095M parameter.

 

Thanks, added mem=4095M and rebooting, will post back when I see results !

 

Hey, back from my reboot, just to confirm, mem=4095M is to be added to syslinux.cfg( I placed as last line ) and then reboot the server and all should be well ?

I am still getting the same abysmal write speeds, however it appears that its still using 8gb of ram:

 

Memory Info

 

(from /usr/bin/free)

 

            total      used      free    shared    buffers    cached

Mem:      8197192    733800    7463392          0      4420    654100

-/+ buffers/cache:      75280    8121912

Swap:            0          0          0

 

 

Thanks for your time.

If you really did add it as the last line in the file then that would be wrong.  It should be something like this
default menu.c32
menu title Lime Technology LLC
prompt 0
timeout 50
label unRAID OS
  menu default
  kernel bzimage
  append initrd=bzroot
label unRAID OS (MAX 4GB RAM)
  kernel bzimage
  append  mem=4095M initrd=bzroot    <===== this is where it goes
label Memtest86+
  kernel memtest

from StevenD's post.

 

That config would require you to select unRAID OS (MAX 4GB RAM) when unRAID boots. It would be better just to change "  append initrd=bzroot" to "  append mem=4095M initrd=bzroot", especially if you are one of those people that don't have a monitor/keyboard attached to your server. Correct me if i'm wrong, this is what I use.

 

default menu.c32

menu title Lime Technology LLC

prompt 0

timeout 50

label unRAID OS

  menu default

  kernel bzimage

  append  mem=4095M initrd=bzroot

label Memtest86+

  kernel memtest

My instructions were to show him WHERE to put the edit.  I used what StevenD posted as an example.  I don't need the setting because I don't have the problem.  My VM's only have 3GB in them and are sufficiently fast but are slightly reduced due to SAS expanders.  Don't remember the speeds but will check if your interested next parity check.
Link to comment

Since it worked, I made it my default.  That was just for the original test.

 

default menu.c32
menu title Lime Technology LLC
prompt 0
timeout 50
label unRAID OS (MAX 4GB RAM)
  menu default
  kernel bzimage
  append mem=4095M initrd=bzroot
label unRAID OS
  kernel bzimage
  append initrd=bzroot
label Memtest86+
  kernel memtest

Link to comment

What other 3TB drives do you have and how are they connected?  For parity checking the speed will be determined by the slowest components in the chain, not just by the speed of the parity drive, since all drives are being read at the same time during checking.

 

I have only 2 tb and 3 tb drives, connected either to the m/b sata ports or to my SASLP Card. 

Link to comment

I'm curious about parity check speeds, and what things people can do to improve them.  I have always had parity check speeds that some here have called "unacceptable," in the range of nearly 12 hours.  I got a speed of 10 hours this week with this latest rc. It is still not what I am hoping for - I'd really like to see 6 hrs for my 3 TB 7200 rpm seagate.  My hardware is relatively new, the processor should not be a bottleneck, I have 4 gb of ram, my parity drive uses a m/b sata port, I just can't understand why my parity check should be so long.

 

I apologize for interjecting this in this thread, but if someone could point me to a discussion of this topic, I'd really appreciate it.  I did notice that at the end of this weeks' check I was getting more that 100 MB/s - dont remember the number.  But 160 MB/s would be great.

 

I don't think anyone gets 160MB/s parity checks unless their using SSDs for everything. 100MB/s is very acceptable, i'm still sitting at 60MB/s on hardware that should be getting 100+. My parity checks are between 16-24 hours on anything after beta12a, i've reported it so many times trying to get it fixed that i've given up on the issue. I would kill for 100MB/s again...

 

Upgraded to 5.0rc10 from 4.7.

Everything looks great aside from my write speeds now being abysmal(4-5MB/s avg, spikes to 20MB/s), Reads are 80-90MB/s.

Onboard Realtek 8112L

 

Just a quick peek at your syslog, but nothing jumps out as a problem.  I think the same advice from a couple of posts above yours applies, add the mem=4095M parameter.

 

Thanks, added mem=4095M and rebooting, will post back when I see results !

 

Hey, back from my reboot, just to confirm, mem=4095M is to be added to syslinux.cfg( I placed as last line ) and then reboot the server and all should be well ?

I am still getting the same abysmal write speeds, however it appears that its still using 8gb of ram:

 

Memory Info

 

(from /usr/bin/free)

 

            total      used      free    shared    buffers    cached

Mem:      8197192    733800    7463392          0      4420    654100

-/+ buffers/cache:      75280    8121912

Swap:            0          0          0

 

 

Thanks for your time.

If you really did add it as the last line in the file then that would be wrong.  It should be something like this
default menu.c32
menu title Lime Technology LLC
prompt 0
timeout 50
label unRAID OS
  menu default
  kernel bzimage
  append initrd=bzroot
label unRAID OS (MAX 4GB RAM)
  kernel bzimage
  append  mem=4095M initrd=bzroot    <===== this is where it goes
label Memtest86+
  kernel memtest

from StevenD's post.

 

That config would require you to select unRAID OS (MAX 4GB RAM) when unRAID boots. It would be better just to change "  append initrd=bzroot" to "  append mem=4095M initrd=bzroot", especially if you are one of those people that don't have a monitor/keyboard attached to your server. Correct me if i'm wrong, this is what I use.

 

default menu.c32

menu title Lime Technology LLC

prompt 0

timeout 50

label unRAID OS

  menu default

  kernel bzimage

  append  mem=4095M initrd=bzroot

label Memtest86+

  kernel memtest

 

Tried that with no luck, same crappy speeds :( but thanks for the reply :)

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.