unRAID Server release 4.1 available


Recommended Posts

Download.

 

Ok, sorry to disappoint, this is not the big "security + writable user share" release, those major features will get into 4.2  :-[

 

This is the release we're shipping with the MD-1500 product.  The main features in this release are an upgrade of the linux kernel to the latest stable version (2.6.22.1), and support for 16 hard drives.

 

The reason we upgraded the linux kernel was to get all the latest changes in SATA subsystem.  This release has been well tested on the ASUS P5B-VM DO motherboard.

 

For those with Realtek LAN chips: the latest Realtek manufacturer driver does not compile without error for some reason under 2.6.22.1, so we built in the "stock" linux driver.  There are a series of patches for this driver which should get incorporated in the next major linux release (2.6.23).

 

So if you have a Realtek LAN chip, try this release and let me know if there are problems and we will attempt to address them.

 

unRAID Server 4.1 Release Notes

Upgrade Instructions
--------------------

If you are currently running unRAID Server 4.0-beta1 or higher, it is only necessary to copy the files:
    bzimage
    bzroot
from the new release to the root of your Flash device.  This can be done either by plugging the Flash into your PC or, but copying the files to the 'flash' share on your running server.  The server must then be rebooted.


If you are currently running unRAID Server 3.0-beta1 or higher, please follow these steps to upgrade:

1. Referring to the System Management Utility 'Main' page, make a note of each disks's model/serial number; you will need this information later.

2. Shut down your server, remove the Flash and plug it into your PC.

3. Right-click your Flash device listed under My Computer and select Properties.  Make sure the volume label is set to "UNRAID" (without the quotes) and click OK.  You do NOT need to format the Flash.

4. Copy the files:
    bzimage
    bzroot
    syslinux.cfg
from the new release to the root of your Flash device.

5. Right-click your Flash device listed under My Computer and select Eject.  Remove the Flash, install in your server and power-up.

6. After your server has booted up, the System Management Utility 'Main' page will probably show no devices; this is OK, navigate to the 'Devices' page. Using the model/serial number information gathered in step 1, assign each of your hard drives to the correct disk slot.

7. Go back to the 'Main' page and your devices should appear correctly.  You may now Start the array.


If you are installing this release to a new Flash, please refer to instructions on our website at:

http://www.lime-technology.com/wordpress/?page_id=19


Changes from 4.0 to 4.1
-----------------------

Improvement: support up to 16 hard drives

Improvement: upgrade to linux kernel 2.6.22.1

Improvement: upgrade Intel Pro/1000 driver to version 7.6.5

Improvement: use stock r8169 driver instead of Realtek r1000/r8168 driver

Improvement: add JMicron PATA support

Link to comment

Hi Tom.  You certainly had me rushing over to the forum when I saw the 4.1 thread, thinking security beta yippee! ;)

 

But a big thank you for a very welcome release to provide the 16 drive support for our 6+2 SATA Motherboards.

 

PS: I'm still very keen to know if you are configuring the MD1500 machines for AHCI mode on the SATA ports, as I have done with my P5B-E setup?

 

ie. I don't think I have seen any official comment on whether this is now the preferred / recommended config.

 

 

Link to comment

Tom,

 

First, thanks for the  interim release... Looks like  I'll eventually have to figure out how to physically mount 4 more disks in the MD1200 case  ;)

 

Will this be the *only* 4.1 release?  If possibly  not, then you are not following your own naming convention as described in the readme.htm page in your downloads folder.

 

When a new release has been developed it will first undergo a beta testing period. Beta releases are tested by a number of highly knowledgeable users within the unRAID Server User Community Forum . The first beta release will have the suffix "-beta1" appended to the version number. Hence, the first release of version 4.1 will actually be "4.1-beta1".

 

Joe L.

Link to comment

Hi Joe. Just thought I would add my views on the points you raise. 

 

I can see what you mean by the version numbering and lack of a beta release, but I would add that this 4.1 release is really no different to the 4.0 final release process in this regard.  ie. If you refer to the change log there were 2 changes made between the last 4.0beta release and the subsequent release that was labelled 4.0 final (so what would have happened if there were issues introduced by these 2 'final release' changes?).

 

Ideally a beta release process should continue until there are no reported issues from 'beta' testing, such that the 'final' stable release has only the version number changed from the last beta compile (ie. so no new issues can possibly be introduced).

 

With regard to version numbering, I agree that the change of a minor version number is necessary for these subtle changes to an already released 4.0 final. However, the issue should really be that the more substantial feature enhancements of both 'security' and 'writable user shares' do really warrant a more significant version number increment than just the equivalent release increment used for the subtle changes that produced this 4.1 release increment?

 

Personally, I would have considered the current release as more of a 4.0.1 release, with the 'security' and 'writable shares' additions still being considered a 4.1 release increment.

 

Apologies for rambling Tom, but also being a software developer you tend to focus on these sorts of things. ;)

 

Link to comment

Good points Koolkiwi,

 

Version 4.1 was produced specifically for the MD-1500 product, where we needed to have 16-drive support.  While it is a pretty significant change going from linux kernel 2.6.20 to 2.6.22.1, we extensively tested on the MD-1500 platform.  Probably, version 2.6.20 would have been fine as well, but looking through kernel change logs, we felt it was worth it to pick up all the bug fixes related to SATA.  Probably any problems we see in 4.1 will be related to h/w not in the MD-1500.

 

As for your earlier question about AHCI, yes we set all the motherboard SATA controllers to operate in AHCI mode.

Link to comment

I'm a tad disappointed; 'cause I really need the writable user share functionality. Having done enough software development; I know what it's like to have to pull features. It isn't pleasant and it's never something anyone wants to do. Well ok, maybe MS likes to do it; but that's another kettle of fish.

 

So Tom, any idea when the betas for 4.2 will start hitting the street? I am looking forward to the writable user shares.

 

Cheers,

 

 

Link to comment
While it is a pretty significant change going from linux kernel 2.6.20 to 2.6.22.1, we extensively tested on the MD-1500 platform.  Probably, version 2.6.20 would have been fine as well, but looking through kernel change logs, we felt it was worth it to pick up all the bug fixes related to SATA.

 

Thanks for the clarification Tom.  I overlooked the kernel change, which of course is a significant change.

 

I would also agree that moving to a later kernel to pick up related bug fixes is a very good move, ahead of adding new features.  I would much prefer new features are added to as stable a base as possible, rather than building on wobbly foundations! ;)

 

John: Please have patience, we are all awaiting these new features, I'm sure Tom will release 4.2beta when it is good and ready.

Link to comment

I just found out that some of my old hardware seems to work great with UnRaid, so I'm already half way to another build, using much of that older gear. Of course I won't know for sure until I get all the hard drives hooked up, but I know UnRaid recognized drives attached to my RocketRaid 454.

 

What's the advantage of using AHCI mode? Any problem with shifting to AHCI after formatting, etc.?

 

Link to comment

 

Ok, sorry to disappoint, this is not the big "security + writable user share" release, those major features will get into 4.2  :-[

 

 

disappointing, but understandable. Tom, the work you put into unRAID is appreciated, I hope you do well business wise by it. Anyways, the writeable shares is a big thing for my (planned) setup. Are you able to give any kind of ETA on 4.2? It would help me and I'm sure others in their plannings. I understand it would be a "rough" estimate, and it wouldn't be fair to hold you to it, but it would be nice to have a better idea then "someday". Thx  :)

Link to comment

I'm just wondering on the algorith for the writable shares (what goes on which physical drive) ... will it keep subdirectories together such as ripped DVDs with title\video_ts folders?

 

To me, the way it is now isn't at all a big deal as I rip to the physical drive anyway. It will be nice not to have to rescan the user-shares every time though.

Link to comment

well, the only problem with implementing that is that SAMBA comes down when they are rescanned, so if you are moving files to the server or watching a movie or listening to music, etc, your connection is lost at the time of the rescan. I believe as part of the writable shares, however, the "re-scan" will be dynamic and will show up automatically, without SAMBA coming down

Link to comment

What's the advantage of using AHCI mode? Any problem with shifting to AHCI after formatting, etc.?

 

Refer my post over here (with reference link):

http://lime-technology.com/forum/index.php?topic=571.msg3710#msg3710

 

ie. AHCI has full driver support for SATA features such as NCQ, instead of emulating SATA as a PATA drive.

 

What performance benefit for unRAID is (if any) I have not tried to test, but possibly more significant in terms of hardware support. ie. The single fully functional AHCI driver will likely work with any AHCI compatible controller (eg. The jMicron).

 

Also can't answer the formatting question, although I would not have thought this would affect the existing data on the drive?

 

Can anyone else chime in here?

Link to comment

AHCI is the way of the future for SATA.  Works great, does not affect on-disk format at all.

 

Enhanced user shares feature offers 2 allocation algorithms to choose on a share-by-share basis:

1. "most-free" - whenever a new file is created on a share, it's created on the disk with the most free space.

2. "highwater" - whenever a new file is created on a share, it's created on the disk with the least amount of space which is still above the current highwater value.  Once no disk has any space above the current highwater value, the highwater value is divided by 2, and a disk is chosen.  For example, suppose you have 3 100GB data disks.  Initial highwater is set at 50GB.  Files will get created on disk1 until disk 1 free space is less than 50GB, at which point we start allocating from disk2.  When disk2 free space drops below 50GB we start allocating from disk3.  When disk3 free space gets below 50GB, we now set highwater to 25GB, and disk1 starts getting used, etc.

 

In addition, you can specify the name of "unsplittable" directories.  For example, suppose you designate "VIDEO_TS" as unsplittable.  Then if a file  needs to be created in the VIDEO_TS directory, it will get created on the disk where that VIDEO_TS directory currently exists, overriding the allocation algorithm.

 

Finally, you can restrict the set of disks that a share can use - that is, you can explicitly list the set of disks which may have space allocated to a share, or you can list a set of disks which are excluded from the share.

 

Also, no more re-scan button  :)

Link to comment
Also, no more re-scan button  :)

 

Thanks for the info Tom.

 

Just to clarify though... is the re-scan button truly gone altogether? Not just in regard to writable user shares?

 

ie. If writing to the existing individual drive shares will it also no longer be necessary to "re-scan"?

 

And if so (which is fantastic by the way), I assume the automated process will not reset the user shares network connections like the current "re-scan" button does.  ie. So you could be watching a movie (uninterrupted), while completing a write to the unRAID server?

 

Link to comment

 

So you could be watching a movie (uninterrupted), while completing a write to the unRAID server?

 

 

I think it works that way today, what you can't do is complete a write to the unraid server, HAVE THE NEW MOVIE/SONG SHOW UP FOR USER#1, while user#2 is watching a movie (uninterrupted).

 

Right?

 

 

Bill

Link to comment

There is no inherant limitation to have to stop and re-start SAMBA to get it to re-read the smb.conf file.  It can be sent a signal to perform that task.

 

Tom's current implementation of user-shares stops SAMBA and re-starts it when the "SCAN" button is pressed.  Today, that "SCAN" button actually deletes and re-constructs the ram-disk mounted as /mnt/user  It is there that the user-shares are currently created.

 

I have edited my smb.conf file to hide my "data" share and then typed the following commands to have it take effect.

kill -HUP `pidof smbd`

kill -HUP `pidof nmbd`

 

I did this while I was playing a movie being served from a unRaid  user-share on a network media player.  The Movie was not interrupted and SAMBA did not disconnect.

 

So... currently it is not possible to press the "SCAN" button while reading or writing the unRaid server without the read or write being interrupted as SAMBA is stopped and re-started.

 

Hopefully, in the future SAMBA will be sent the HUP signal and not have to disconnect.  It would be really bad if it did every time a new file was created.  It will be interesting to see how Tom handles the addition of a new top level folder representing a new user-share.  unRaid 4.2 will be interesting.

 

Joe L.

Link to comment

how do you determine the PID of the service? SMBD shows up in the TOP command, but not the NMBD

You could type the command exactly as I typed it in my prior post, with the back-quotes, and it will do the work and supply the correct process ID to the kill -HUP command...

 

or

 

Type

ps -ef | grep nmbd

 

or

pidof nmbd

 

Either will print the PID for you to use.

 

Note that smbd has several processes running, you would want to send the kill -HUP signal to all of them.  Again, typing

pidof smbd will show you  all of them.  so will ps -ef |grep smdb

 

If you really don't care about the specific process IDs and just want the smb.conf to be re-read,you can type:

kill -HUP `pidof smbd`

kill -HUP `pidof nmbd`

Joe L.

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.