unRAID Server Release 5.0-beta4 Available

My router is my gateway and DNS server (as normal):

Ethernet adapter Local Area Connection:

  Connection-specific DNS Suffix  . :

  Description . . . . . . . . . . . : Atheros AR8121/AR8113/AR8114 PCI-E Ethernet Controller

  Physical Address. . . . . . . . . : 00-22-15-96-97-09

  DHCP Enabled. . . . . . . . . . . : Yes

  Autoconfiguration Enabled . . . . : Yes

  Link-local IPv6 Address . . . . . : fe80::fc86:269a:5399:2578%12(Preferred)

  IPv4 Address. . . . . . . . . . . : 192.168.1.100(Preferred)

  Subnet Mask . . . . . . . . . . . : 255.255.255.0

  Lease Obtained. . . . . . . . . . : Sunday, February 20, 2011 7:56:21 AM

  Lease Expires . . . . . . . . . . : Monday, February 21, 2011 7:56:21 AM

  Default Gateway . . . . . . . . . : 192.168.1.1

  DHCP Server . . . . . . . . . . . : 192.168.1.1

  DHCPv6 IAID . . . . . . . . . . . : 251666965

  DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-F2-E7-10-00-22-15-96-97-09

  DNS Servers . . . . . . . . . . . : 192.168.1.1

  NetBIOS over Tcpip. . . . . . . . : Enabled

When will beta5 be released?

When will beta5 be released?

No one knows but LimeTech

Since the way drives are being detected, registered and store in the disk.cfg there is probably a lot of testing that has to be done to make sure it is working.

When will beta5 be released?

Final testing now.  Release notes are published:

http://lime-technology.com/wiki/index.php?title=UnRAID_Server_Version_5.0-beta5_Release_Notes

Big Change is elimination of "slot" concept.

Final testing now.  Release notes are published:

Well dang... you incorporated at least 3 ideas I had for separate plugins!

Looking forward to giving the next release a proper go of things. 

When will beta5 be released?

 

Final testing now.  Release notes are published:

http://lime-technology.com/wiki/index.php?title=UnRAID_Server_Version_5.0-beta5_Release_Notes

 

Big Change is elimination of "slot" concept.

Can you update the roadmap to reflect the current and future state of developement?

What is slot concept?

What is slot concept?

It's the idea that there are fixed locations, or 'slots' that you can plug a hard drive into.  For example, consider a case with 4-in-3 tray-less drive cages.  Each "slot" in a drive cage holds a single drive which is connected via SATA cable to a single SATA port, either on the motherboard or add-on disk controller card.

In pre-5.0-beta5, when you "assign" disks on the "Disk devices" page, even though the hard drives are listed by model and serial number, what is getting stored in config data is the "slot id", or rather, the linux path-id of that device.  Later when you Start the array, the actual device model and serial number is stored in the md-driver 'super.dat' file, but the linux path-id is what is stored in the 'disk.cfg' file.

Why is this handy?  For a number of reasons:

a) on the Main page, "parity" , "disk1", "disk2", etc. refer to physical slots.  So if you label your slots, you will always know which disk is parity, disk1, etc.

b) if a disk gets disabled, you know exactly which one it is (assuming your slots are labeled).

c) the software can detect many types of array configuration changes automatically, for example, if you remove a disabled disk and later re-install a new disk, software can detect this because it can notice that a new disk has been plugged into an existing slot.

Anyway having fixed 'slots' is useful for maintenance purposes - it just makes disk removal/installation more fool-proof.

But.. too bad, can't implement this reliably anymore 

Thank you for the explanation.

First of all, before it gets lost in the rest of this...what does the new 'identify' button do?  If it make's the drive's 'busy' light blink, then I think that would be quite useful.  That's the only way I can think of to physically identify a drive in a server (without pulling the drive and looking at its serial number).

I'm all for the elimination of the 'slot' concept.  Identifying drives by their serial number instead of their Linux hardware ID opens the doors for more automation in the drive replacement process.  Of course there should still be manual overrides as many advanced unRAID users prefer to assess the situation before taking any action.  However, I see no reason why there shouldn't be a built-in option to have an emulated disk automatically rebuild onto the first new drive that is installed.  This would be a significant new feature to small business users who have no qualms with spending $100 on a new drive to make sure their data is safe (as opposed to many home users who would prefer to spend the time to make sure the disabled disk is truly due to disk failure and not due to a defective motherboard port, cable, or drive bay).  As a home user, I would also use this feature as I would prefer to automatically replace a disabled disk with a warm spare, then later test the disabled disk on another machine to see if the disk actually failed or if there might be another problem in my system.  I know the idea of replacing a disabled disk with a new hard drive without first testing the integrity of the other links in the chain (the motherboard ports, SATA controller, cable, drive bay, etc.) is a scary one to some users...but what is really so bad about that situation?  The only way you would actually lose data is if you had a widespread failure of more than one drive.  The only way I can think of this actually happening is a PSU frying multiple drives.  Maybe I'm over-simplifying the issue, if so then please offer other worst-case scenarios.

The other fringe benefit of this change is that an unRAID user can swap their motherboard and/or SATA controller cards without having to re-assign their drives to the correct slots.  This is important as the current process absolutely requires that a user assign the parity drive to the correct slot, as otherwise a data drive could be accidentally overwritten and data could be lost.  As long as the motherboard/SATA controller correctly reports the drive's serial number to unRAID, there should be no need for user intervention during the first boot with new hardware (except possibly to assign the flash drive as the primary boot device in the new motherboard's BIOS...but I digress).  I suppose the only question would be "what if the motherboard or SATA controller reports the wrong drive serial number to unRAID?"  I don't know of any case in which this has actually happened, but it comes to mind as a worst-case scenario.

A secondary fringe benefit is that users could re-arrange their hard drive to optimize speeds without worry of messing anything up.  This isn't much of a concern for modern systems that use only PCIe, but older systems with PCI bottlenecks could benefit from this.

Anyway having fixed 'slots' is useful for maintenance purposes - it just makes disk removal/installation more fool-proof.

I don't think I follow you here.  What is more fool-proof about the current 'slot-aware' system?  It seems to me that it is somewhat more dangerous as a data drive could be accidentally overwritten with parity data in the scenario of motherboard/SATA controller replacement.  Perhaps you mean that the current system allows unRAID to identify any new hard drive installed in the same physical slot as a disabled hard drive as a replacement.  While this is a handy feature, what's wrong with just assigning the first new drive installed in the array after a disabled disk is identified as that disk's replacement?

Fake edit: As I was typing this I realized the issue with the above.  I'll leave it there so that I can 'show my work' and perhaps others will come to the same conclusion...

OK, I see the issue now.  What happens with drives not assigned to the array?  This could be a cache drive, a warm spare, or a SATA or eSATA drive mounted with SNAP.  Any drive not assigned to the array could potentially be mistaken by the unRAID software as the replacement for a failed disk.  This could result in unRAID attempting to use a completely unfit drive as a automatic replacement for a failed disk.

I'm not sure this is an 'end of the world' kind of situation, but it is still something worth consideration.

The way I see it, if in unRAID Next a user could designate a drive or even a set of drives as being "hot-spare" then unRAID could automagically rebuild onto one of the drives it found suitable (same drive size or larger, not mounted, and maybe not partitioned?).

At the worst case, a user has to select a drive to designate it as a replacement for the failed drive. This would be similar to how it works now, aside from unRAID auto-detecting the replacement by slot, as it still requires user confirmation to proceed.

Raj, unRAID should not ever be allowed to randomly select a drive from the population of drives that aren't already part of the array to rebuild on  because there will be drives in many systems that are not intended to be part of the array.  

Either:

1. User puts new drive in same slot (not possible in v5 now)

2. User assigns drive(s) as warm spares

3. User selects replacement drive at time of replacement.

SNAP needs to be able to determine if a drive is a part of the array or if it is intended (assigned) as a warm spare to prevent mixups so if there are to be warm spares I would like to be able to call an api for a list of warm spare drive ids (so I'm in favor of #2).

Also, I can see a situation where one or more drives were being precleared and unexpectedly a failed drive causing unRAID to select a warm spare.  Using #2 above would prevent an improper automatic selection.  Say for instance the parity drive was 2TB and the preclearing drives were 3TB.  In that situation unRAID should select only those drives designated as warm spares or should do nothing which would allow the user to take manual steps in assiging the replacement drive.

Disks will still be assigned, but it will be by serial number, and moving it to a different port on a different controller, or rearranging the drive cables, won't matter any more.

So IIUC, basically you label your drive trays (not the slots) with the disk number assigned to the drive in that tray, and you can plug that tray into any port.

Big Change is elimination of "slot" concept.

Hallelujah!

My only concern with this is possible issues with VM disks that might have identical serial numbers.  Not sure if that is possible, but just a thought.

I have always hated that unRAID wants to assign a disk to one of my slots on its own.  I once had a drive wiggle loose during a disk rearrangement and the next thing I knew unRAID was going to rebuild a disk onto my cache drive!  And it is extremely easy for your cache drive to be exchanged for another disk if you aren't careful.

My suggestion is to keep the user in charge and not do automatic assignments to slots.

IMO, I found the concept of "slots" a little odd. I'm guessing part of the reason it was added was to visualize the array for people who aren't familiar with linux. To anyone who's familiar with the native Linux MD driver will know that it has the capacity to reassemble RAID arrays without having to be told in which order the drives are located.

It is "smart" enough to look at all drives connected to a system and attempt to reassemble the array based on the identifier (UUID) on each disk.

Prior to coming to unRAID, I ran a Ubuntu server with 5 disks in a RAID5 array and my boot sequence was a simple line to reassemble the array. If one or more of the drives aren't found, it simply fails elegantly.

I, for one, welcome this new addition to unRAID.

My suggestion is to keep the user in charge and not do automatic assignments to slots.

What do you have your DNS server set to on your Win-XP box?   It would normally be set to the IP address of your router.  The router, in turn, should have its DNS server name set to your ISPs domain name server (Or some other DNS server you might prefer)

 

Frequently, windows ends up being set by your ISP/browser to your ISP's domain name server.  Then all requests for name translation go there first, and then possibly to your local lan. (if they do not re-route it to one of their "help" pages)

My DNS server is my router, which has DHCP reservations for all my machines. I noticed that my Windows machines are appending .earthlink.net to names like "tower". I guess that's why my router is failing to provide the IP. I could have sworn that this used to work fine... Anyway, I put the server name and IP in c:\windows\system32\drivers\etc\hosts.

What do you have your DNS server set to on your Win-XP box?   It would normally be set to the IP address of your router.  The router, in turn, should have its DNS server name set to your ISPs domain name server (Or some other DNS server you might prefer)

 

Frequently, windows ends up being set by your ISP/browser to your ISP's domain name server.  Then all requests for name translation go there first, and then possibly to your local lan. (if they do not re-route it to one of their "help" pages)

 

My DNS server is my router, which has DHCP reservations for all my machines. I noticed that my Windows machines are appending .earthlink.net to names like "tower". I guess that's why my router is failing to provide the IP. I could have sworn that this used to work fine... Anyway, I put the server name and IP in c:\windows\system32\drivers\etc\hosts.

Come on Beta 5!!!! 

Tom, do you think this will be the last beta before RC?

Come on Beta 5!!!! 

 

Tom, do you think this will be the last beta before RC?

According to the Roadmap there are still a few things Tom would like to implement for 5.0 final so I expect there will be more releases (2-3 likely) before we see RC.

Come on Beta 5!!!! 

 

Tom, do you think this will be the last beta before RC?

If the next release is stable enough, I just might risk my server and use it. As long as Airvideo and subsonic continues to work properly with the new release, then I am set.

If the next release is stable enough, I just might risk my server and use it.

I'm running beta4 on my one and only server - I have no problems with it.  In fact, with all the improvements, I'd be loath to go back to 4.x.

I'm sure that there has been some change in the way that the boot device is recognised - since upgrading to 5, I've not had any occurrence of the intermittent failure of boot completion where the bzimage and bzroot images would load from the flash, but then the flash drive would fail to mount on the running system.

Come on Beta 5!!!! 

 

Tom, do you think this will be the last beta before RC?

 

If the next release is stable enough, I just might risk my server and use it. As long as Airvideo and subsonic continues to work properly with the new release, then I am set.

Some advice on when to start using betas and new releases

What is the "SLOT" concept thing?