unRAID Server Release 5.0-rc1 Available


Recommended Posts

  • Replies 331
  • Created
  • Last Reply

Top Posters In This Topic

ok, parity check complete. varied between ~30mb/sec and 80+mb/sec. I believe that's more HDD speed than UnRaid. Seemed to get faster as my older/smaller drives completed the check.

 

Done permission update and able to access my shares fine :)

 

spun down all drives and spun them up by accessing a share and playing a movie.

 

using the onboard intel and an IBM BR10i (LSI 1068 chipset, I believe) for my drives.

Link to comment

upgraded to rc-2 test build.....im running a M1015 reflashed to LSI SAS9211-8i P13 spun down drives.....spun up drives.......log is clean...... ;D ;D ;D ;D ;D.....parity sync......60-80mb/s.......im very happy........write speed solid at 65mb/s to cache drive

 

FYI: drives are WD30EURS, and WD20EVDS

Link to comment

Regarding RC2-test:

 

Mounted the array, spun down all drives, spun up, spun down again then initiated a parity check.

 

This sequence always led to those terrible  errors related to mpt2sas driver and kernel 3.1+. In RC2-test this didn't happen!!! The emhttp and the md driver correctly stated the power status from the drives and woke them up prior to the access, avoiding the bug to happen!

 

Thank you so much, Tom!

 

PS. This is an early report, but parity check seem a bit faster too, about 10MB/s faster than in B12a. Will report again when the check finishes.

 

 

Link to comment

I'm using a system with a SASLP-MV8, with beta14 I'm getting speeds of about 60MB/sec average for paritycheck, however, with the rc2-test version, I'm only getting speeds of up to 20MB/sec for paritycheck, in the same situation.

Reading and writing didn't test the speed, but in normal usage appear the same in both, so not slow like that.

Link to comment

Way to go Tom, sounds like 5.0-Final is finally around the corner.

Job well done mate, and don't let any of those bad-mouthers tell you otherwise.

unRAID is fantastic value for money and I look forward to purchasing additional licenses in the future.

 

Keep up the good work  ;D

Link to comment

I'm using a system with a SASLP-MV8, with beta14 I'm getting speeds of about 60MB/sec average for paritycheck, however, with the rc2-test version, I'm only getting speeds of up to 20MB/sec for paritycheck, in the same situation.

Reading and writing didn't test the speed, but in normal usage appear the same in both, so not slow like that.

 

I use that controller extensively and don't see any parity check slowdown; if anything it's faster with -rc2-test.  Is that the only controller in your array?  Also note parity check/sync starts out fast, but will always slow down considerably as it's progress reaches more toward the spindle of the hard drives where the data rate becomes slower.

Link to comment
Is that the only controller in your array?

 

I also have two drives on the motherboard, which is an asus a8n32-sli deluxe (no corruption fortunatly).

Did some more testing, the raw speed is indeed faster, I'm getting about 10-15mb/sec more with the rc2-test.

The difference seems in accessing through samba, accessing a share makes the parity-check slow down (since it has to read other stuff) and then speed up again, which explains the low speeds that I saw, but the difference is that beta-14 seems to go back to full speed faster than rc2-test does (seconds, instead of minutes).

Knowing what happens, I don't consider it vital, but since it was a big difference I wanted to make a post about it. I'd say ignore it, because I can't exclude that windows secretly was doing something with the share that makes the tests different, and everything works correctly regarding data-integrity and access and so on. So in real-life-situations, no big deal.

Link to comment

[RC1] With an active SMB connection and pressing "spin down" all drives will spin down, which interrupts the active stream briefly.

 

In previous versions any drive with active connections would not spin down, this is what I expect as behaviour.

This is now working correctly (again) in rc2-test.

 

Finished a parity check and average speed is back to 63.7 MB/s, that is what I used to have.

 

I have a realtek ethernet port, driver R8169 is used and in transfering files in both directions goes within problem, it saturates my 100 Mbps link - in other words no slowness observed.

 

All in all this version gives me a better impression than rc1.

 

Link to comment

I'm using a system with a SASLP-MV8, with beta14 I'm getting speeds of about 60MB/sec average for paritycheck, however, with the rc2-test version, I'm only getting speeds of up to 20MB/sec for paritycheck, in the same situation.

Reading and writing didn't test the speed, but in normal usage appear the same in both, so not slow like that.

 

I use that controller extensively and don't see any parity check slowdown; if anything it's faster with -rc2-test.  Is that the only controller in your array?  Also note parity check/sync starts out fast, but will always slow down considerably as it's progress reaches more toward the spindle of the hard drives where the data rate becomes slower.

 

I also have AOC-SASLP-MV8 and it flies through the parity check...  Starts at 115MBytes/sec, finishes at around 55Mbytes/sec

 

My 12TB server set up -

    Asrock H67M-ITX, i3-2125 CPU, 4GB RAM; (LAN chip is RTL8111E)

    four drives on AOC-SASLP-MV8, remainder on the motherboard;

    drives are 6 data x 2TB (WD20EARS green), parity 2TB (WD20EARS green on motherboard), cache 1TB (WD10EADS green on motherboard)

Parity check (corrections disabled) - 6 hrs 25 minutes - same on RC1 and RC2.

 

RC2 is much better writing to cache than RC1 but not quite up to the speed seen on 5.0b14.

 

Only problem I have is that the server always seems to come up without the array being started.  I do not get that problem with B14 or RC1.  I am just swapping bzroot and bzimage files to hop between versions at this time - is that OK?

 

Link to comment

 

Tom, I fear to ask, but seeing you in good mood I give it a go:

Would it be possible by any chance to have Multimedia, Video for Linux and DVB for Linux modules in their as well to make it easy to run TVHeadend? Currently this requires massive customization and recompiling the kernel.

 

I don't think this would generate any overhead (other than the slightly bigger package file) to those who don't use this, would it?

 

+1

 

Shall we get the core hardware working before we start bolting on extras?

 

Save it for 5.1? ;)

 

Well,  PPP is not quite core either.

We can argue on vmxnet driver, but I wouldn't consider this to be core either.

 

My request doesn't require development and can be done in no time, just like PPP and vmxnet driver, so wouldn't delay anything for you. Just because you don't use something, don't jump on someone who does.

 

If this feature requires kernel support, and you can tell me what I need to configure in the kernel, I have no problem turning on the feature and rebuilding the kernel.  It won't affect any other functionality, other than adding to the size of the kernel, and RAM footprint it requires.

 

Limetech : This would would much appreciated by a lot of people if DVB and Multimedia support could be added. A lot of people use unRAID as a "LiveTV" server s opposed to having two boxes.

 

The details of which modules are required can be found here : http://lime-technology.com/forum/index.php?topic=14129.15 Its a little bit of a read but im away from home to go through what i did and cant remember exactly either.

 

Thank You for a great job in unRAID

Link to comment

It isn't like me to really jump in these threads, but I feel like this point should be stated. I've noticed that there have been several folks that have asked for enhancements (some may make a point to say that they aren't enhancements, but nonetheless, they are changes that were not originally planned for) which is the epitome of scope creep. I deal with it quite often in my work as a software project manager for the government. These requests are coming at the 11th hour when limetech is attempting to get out the next stable release. Limetech is obviously wanting to do the right thing and include as much as possible, but no matter the complexity of the change, whether it takes coding/development or a simple switch during kernel compilation, all have consequences and should be rolled out incrementally and well tested.

 

This isn't to say that limetech should not be entertaining the requests, but they should be in a queue of work, advertised what's in that queue, and then incrementally test and roll the changes (details left out).

 

So, what I'm suggesting is that limetech be free to complete 5.0 (stable, without all the requests included right now) and maybe start a new thread somewhere, maybe there is already a place, to request changes and so forth so they can be planned accordingly. I have a few requests myself, but I don't want to muddy the water here...

 

Ok, I'll get off my soapbox already! Hope it makes some sense.

 

Thanx,

Link to comment

 

RC2 seems to be working great... for me anyway  :o8)

 

Over a SMB gigabit LAN, Intel NICS , Windows7 (reading & writing to a SSD), moving Blu-Ray MKVs, I get

  read from share ~80 MB/S

  write to share (no cache drive) ~40 MB/S

  write to share (w/cache drive) ~73MB/S

 

 

Parity Check(correct) run through at 88.3 MB/S  :)

 

The results are from my backup/test server using 13) 1.5 WD Blacks on 2) flashed M1015s... ;D ;D

 

No errors in the system log after multiple spin up/downs, & numerous read/writes.

 

Thanks Tom !!!

 

Link to comment

It isn't like me to really jump in these threads, but I feel like this point should be stated. I've noticed that there have been several folks that have asked for enhancements (some may make a point to say that they aren't enhancements, but nonetheless, they are changes that were not originally planned for) which is the epitome of scope creep. I deal with it quite often in my work as a software project manager for the government. These requests are coming at the 11th hour when limetech is attempting to get out the next stable release. Limetech is obviously wanting to do the right thing and include as much as possible, but no matter the complexity of the change, whether it takes coding/development or a simple switch during kernel compilation, all have consequences and should be rolled out incrementally and well tested.

 

This isn't to say that limetech should not be entertaining the requests, but they should be in a queue of work, advertised what's in that queue, and then incrementally test and roll the changes (details left out).

 

So, what I'm suggesting is that limetech be free to complete 5.0 (stable, without all the requests included right now) and maybe start a new thread somewhere, maybe there is already a place, to request changes and so forth so they can be planned accordingly. I have a few requests myself, but I don't want to muddy the water here...

 

Ok, I'll get off my soapbox already! Hope it makes some sense.

 

Thanx,

 

I agree here. We are at a release candidate level, and going back to sort of a beta testing level.

It's too much which is why it's taken 5.0 to reach a stable level.

 

There's some USB and IDE/CDROM modules I would love to see part of the kernel too.

Even if they were only compiled and the modules were secondary addons.

 

Perhaps the next beta can be a kernel module release only.

 

Link to comment

If this feature requires kernel support, and you can tell me what I need to configure in the kernel, I have no problem turning on the feature and rebuilding the kernel.  It won't affect any other functionality, other than adding to the size of the kernel, and RAM footprint it requires.

 

Many thanks for picking this up Tom!

 

I am willing to summarize you what is needed, but can you advise what approach should we take to support different cards?

I can tell you exactly what is needed to support my card (...and alxscott's), but there are plenty of cards out there.

 

Shall we add only those cards/adapters we know about or add all (that would be a bigger footprint impact)?

Link to comment

I'm using a system with a SASLP-MV8, with beta14 I'm getting speeds of about 60MB/sec average for paritycheck, however, with the rc2-test version, I'm only getting speeds of up to 20MB/sec for paritycheck, in the same situation.

Reading and writing didn't test the speed, but in normal usage appear the same in both, so not slow like that.

 

I use that controller extensively and don't see any parity check slowdown; if anything it's faster with -rc2-test.  Is that the only controller in your array?  Also note parity check/sync starts out fast, but will always slow down considerably as it's progress reaches more toward the spindle of the hard drives where the data rate becomes slower.

 

I also have AOC-SASLP-MV8 and it flies through the parity check...  Starts at 115MBytes/sec, finishes at around 55Mbytes/sec

 

My 12TB server set up -

    Asrock H67M-ITX, i3-2125 CPU, 4GB RAM; (LAN chip is RTL8111E)

    four drives on AOC-SASLP-MV8, remainder on the motherboard;

    drives are 6 data x 2TB (WD20EARS green), parity 2TB (WD20EARS green on motherboard), cache 1TB (WD10EADS green on motherboard)

Parity check (corrections disabled) - 6 hrs 25 minutes - same on RC1 and RC2.

 

RC2 is much better writing to cache than RC1 but not quite up to the speed seen on 5.0b14.

 

Only problem I have is that the server always seems to come up without the array being started.  I do not get that problem with B14 or RC1.  I am just swapping bzroot and bzimage files to hop between versions at this time - is that OK?

 

I had a similar problem with the array not starting after I had to rebuild my system due to a bad flash drive. Here's the fix from prostuff1:

 

as for the array not starting:

 

set it to no, hit apply, hit done, reboot, set to yes, hit apply, hit done, reboot.  The array should start.

 

I didn't expect this to work, but it did. Full thread here:

 

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

 

-Rick

Link to comment

It isn't like me to really jump in these threads, but I feel like this point should be stated. I've noticed that there have been several folks that have asked for enhancements (some may make a point to say that they aren't enhancements, but nonetheless, they are changes that were not originally planned for) which is the epitome of scope creep. I deal with it quite often in my work as a software project manager for the government. These requests are coming at the 11th hour when limetech is attempting to get out the next stable release. Limetech is obviously wanting to do the right thing and include as much as possible, but no matter the complexity of the change, whether it takes coding/development or a simple switch during kernel compilation, all have consequences and should be rolled out incrementally and well tested.

 

This isn't to say that limetech should not be entertaining the requests, but they should be in a queue of work, advertised what's in that queue, and then incrementally test and roll the changes (details left out).

 

So, what I'm suggesting is that limetech be free to complete 5.0 (stable, without all the requests included right now) and maybe start a new thread somewhere, maybe there is already a place, to request changes and so forth so they can be planned accordingly. I have a few requests myself, but I don't want to muddy the water here...

 

Ok, I'll get off my soapbox already! Hope it makes some sense.

 

Thanx,

 

I agree here. We are at a release candidate level, and going back to sort of a beta testing level.

It's too much which is why it's taken 5.0 to reach a stable level.

 

There's some USB and IDE/CDROM modules I would love to see part of the kernel too.

Even if they were only compiled and the modules were secondary addons.

 

Perhaps the next beta can be a kernel module release only.

 

 

+1

 

Also for older systems with limited RAM, I would prefer to see a streamlined kernel with only the necessities.  Maybe, ultimately, two versions, one with a fully featured kernel and one without.

Link to comment

It isn't like me to really jump in these threads, but I feel like this point should be stated. I've noticed that there have been several folks that have asked for enhancements (some may make a point to say that they aren't enhancements, but nonetheless, they are changes that were not originally planned for) which is the epitome of scope creep. I deal with it quite often in my work as a software project manager for the government. These requests are coming at the 11th hour when limetech is attempting to get out the next stable release. Limetech is obviously wanting to do the right thing and include as much as possible, but no matter the complexity of the change, whether it takes coding/development or a simple switch during kernel compilation, all have consequences and should be rolled out incrementally and well tested.

 

This isn't to say that limetech should not be entertaining the requests, but they should be in a queue of work, advertised what's in that queue, and then incrementally test and roll the changes (details left out).

 

So, what I'm suggesting is that limetech be free to complete 5.0 (stable, without all the requests included right now) and maybe start a new thread somewhere, maybe there is already a place, to request changes and so forth so they can be planned accordingly. I have a few requests myself, but I don't want to muddy the water here...

 

Ok, I'll get off my soapbox already! Hope it makes some sense.

 

Thanx,

 

I agree here. We are at a release candidate level, and going back to sort of a beta testing level.

It's too much which is why it's taken 5.0 to reach a stable level.

 

There's some USB and IDE/CDROM modules I would love to see part of the kernel too.

Even if they were only compiled and the modules were secondary addons.

 

Perhaps the next beta can be a kernel module release only.

 

 

+1

 

Also for older systems with limited RAM, I would prefer to see a streamlined kernel with only the necessities.  Maybe, ultimately, two versions, one with a fully featured kernel and one without.

 

 

I don't think two versions are necessary, but some fancy packaging would help.

Base unRAID, with all the kernel modules compiled so the symbols are there, but only include the bare essential modules.

Then an "EXTRA" slack ware package that installs all the supplementary modules so users can use/test whatever hardware support is available in the kernel.  It's a bit of work, but it can be scripted nicely.

 

 

This is probably a subject/suggestion for another thread.

 

 

The core goal for us all is a working 5.0 stable. so while we have limetech's attention, let's feed all the data necessary for that.

Link to comment

Here is the link for "unRAID OS 5.0-rc2-test".  If you have been following along in this thread, and you have an LSI controller, or you have a Realtek NIC, please give it a try and let me know what issues you find.  I'm expecting everything to be great.  I'm seeing 90+MB/sec read via Samba (win7), and around 47MB/sec write to cache drive - not happy with the write speed, it should be better going to cache.  Also parity sync/check speed has no slow down on any of my test systems.  Note that I have NOT addressed any issue with webGui appearing to "hang" - if you let it sit long enough, it seems to come back.  I realize this is not ideal and will address in rc3.  For now I want to know if LSI chipset issues are solved and Realtek NIC's still work  ;)  If so, I'll release as "official" -rc2, and then work on the webGui issues.

 

That is a great new Tom, thanks!  :)

 

Could you please improve the security by default?

 

- Disable Telnet

- Install OpenSHH and change default port (22) to 18xx

- Disable FTP and only allow SFTP

 

Change default port of http://tower:80 to something else..

 

Thanks!

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.