unRAID Development

[greybeard]

Anyone know for sure that Tom is well and continuing to develop and support unRAID? Have not seen a forum message from him in over two months.

[boof]

This is 'normal' and two months is a long way from the record absence.

 

We won't know the answer to your question until he starts posting again or unraid drifts into obsolescence over time.

 

Get used to it I'm afraid, it's how it is.

 

If you have an urgent query you could try emailing limetech directly, historically they have been better at responding there than on the forums. Though there have also been gaps.

[chrisq]

This kind of behaviour is unfortunate and it's screwing Tom over way more than the users. I can't be the only guy waiting for the official 5.0 release before I buy unraid. If he had a more open and continuously updating development system/cycle I would feel differently about shelling out for the 4 series in the hopes that the 5 series shows up some day.

[prostuff1]

This kind of behaviour is unfortunate and it's screwing Tom over way more than the users. I can't be the only guy waiting for the official 5.0 release before I buy unraid. If he had a more open and continuously updating development system/cycle I would feel differently about shelling out for the 4 series in the hopes that the 5 series shows up some day.

 

I understand your sentiment, but the 4.x series is stable and very good. 

 

5.0b2 is out and also works well... I am using it on 2 systems.  There are a some changes in 5.0 (complete rework of the permissions, AFP support, better NFS support, redesign of the webGUI, and the addition of event hooks).  There is a lot of work to get everything integrated into the shfs (User Shares system) also, so that the experience is consistent across the board.

[jj666]

Yes, the 4.5.6 release is working fine here for 80TB of storage (across 2 servers linked together with NFS).  I think that much is worth the subscription alone.  The Unmenu system and the helpful folks on the forum are a great optional and free of charge extra :-)

 

The lack of "official" support is somewhat concerning but as mentioned the current system is fine for my current needs (movie server).

 

Cheers,

 

-jj-

[Rajahal]

Also, upgrades are free, so whenever 5.0 does come out you won't have to pay again.

[chrisq]

I'm still waiting till he shows me the 5 series in stable form, or starts updating on what he's up to. if he made his commit log public I could see him actually doing work and would feel better about paying for this.

[squirrellydw]

what happens if he decides to up the price for 5.x or says no free upgrades after 5.x is released unlesss you bought a previous version?  Don't think it would happen but you never know.  Plus it gives you time to learn how unraid works.

[prostuff1]

There are a few of us on the board that mentioned we would not mind paying for a 5.x version as it is a fairly large change to the web gui along with the other changes.  Tom siad he was not going to charge for it so it was not mentioned again.

[bubbaQ]

if he made his commit log public

 

What makes you think he even uses a CVS?  I have several commercial projects I work on that do not use a CVS.

[BRiT]

I much prefer SVN or GIT over CVS. Don't get me wrong, CVS was fine 10 years ago. It just hasn't moved on from there.

 

[bubbaQ]

I much prefer SVN or GIT over CVS.

 

So do I, but I did not say "CVS" I said "a CVS" -- meaning any concurrent versioning system.

[limetech]

Yes, 5.0 development continues, with 5.0-beta3.  After a period of testing, this -beta3 will become 5.0-final, and I will introduce 5.1-beta1 which is updated with the latest slackware and linux kernel.  It is necessary to update the tool chain and a number of packages in order to properly support AFP which is the #1 development priority.

[Userpaul]

Well I'm happy with what I have seen so far and I have just purchased the unRAID Server "Pro" Registration Key 2-Pack. I have also been impressed with the support here on the forums.

[btlupin]

Yes, 5.0 development continues, with 5.0-beta3.  After a period of testing, this -beta3 will become 5.0-final, and I will introduce 5.1-beta1 which is updated with the latest slackware and linux kernel.  It is necessary to update the tool chain and a number of packages in order to properly support AFP which is the #1 development priority.

 

I am really happy that AFP is getting this kind of attention in the next release. SMB works, but it isn't ideal in a Mac environment. I don't know how large Unraid's Mac user base is, but having the choice of which protocol to use is great.

 

Otherwise UnRaid 4 works great and is stable. The lack of a stable 5 is no reason not to purchase a license (unless you want AFP support that just works).

 

Roland

[Traxxus]

Now we just need to hear about the possible inclusion of 3 TB hard drives, I have heard some of the more notable members say why it wont work now, but I'd like to hear from Tom and what his plans are.

[prostuff1]

As has already been said, but I will say it again...

 

There are issues with the controllers on a lot of motherboards out there, this is NOT just software related.  Granted, Tom can make it so that 3TB drives are supported but he is also going to have buy equipment that can support 3TB drives, 3TB drives themselves, along with a few other things.

 

I believe that most boards out today will NOT support 3TB drives for multiple reasons (ones that have already been listed elsewhere in the forum).

[SSD]

I'd like to at least see Tom move towards starting data sectors on a 4 byte alignment (i.e., sector 64 instead of sector 63) so that 4K drives work without the jumper.  This may be the only true software impediment to moving to larger drives.  (That and additional drivers needed to support controllers that go beyond 2.2T).  Tom mentioned he was considering doing this in the EARS thread, but he decided to defer.  Would probably make for a a difficult transition for existing arrays, but I think we need to do this to be prepared for the next generation of drive expansion.

[prostuff1]

I'd like to at least see Tom move towards starting data sectors on a 4 byte alignment (i.e., sector 64 instead of sector 63) so that 4K drives work without the jumper.  This may be the only true software impediment to moving to larger drives.  (That and additional drivers needed to support controllers that go beyond 2.2T).  Tom mentioned he was considering doing this in the EARS thread, but he decided to defer.  Would probably make for a a difficult transition for existing arrays, but I think we need to do this to be prepared for the next generation of drive expansion.

 

I would agree with this completely.  We need any new drives added to the array to start at sector 64 so that the jumper, wdAlign, etc are not needed.

[bubbaQ]

We need any new drives added to the array to start at sector 64 so that the jumper, wdAlign, etc are not needed.

 

First WDAlign has NO effect when a drive is used in unRAID.

 

Second, the jumper works.  Put the jumper on when you take the drive out of the package, and leave it there.  Problem solved.

 

Not to mention the risk of unintended consequences.  For example, if unRAID starts using sector 64, but you have a WDEARS drive that *has* the jumper, you will send performance into the toilet, just like starting at sector 63 with an WDEARS drive *without* the  jumper.

 

Unless there is some way to query the drive and determine the jumper status, this needs to be left alone w/r/t unRAID. 

 

It is also important to recognize scare resources, and not waste them.  unRAID development time does not need to be wasted on solving problems that are already solved.

 

 

[reggie14]

Second, the jumper works.  Put the jumper on when you take the drive out of the package, and leave it there.  Problem solved.

 

Not to mention the risk of unintended consequences.  For example, if unRAID starts using sector 64, but you have a WDEARS drive that *has* the jumper, you will send performance into the toilet, just like starting at sector 63 with an WDEARS drive *without* the  jumper.

 

Unless there is some way to query the drive and determine the jumper status, this needs to be left alone w/r/t unRAID. 

 

It is also important to recognize scare resources, and not waste them.  unRAID development time does not need to be wasted on solving problems that are already solved.

 

But don't only the Western Digital drives have a jumper?  As far as I know, all the hard drive manufacturers agreed to move to 4k sectors by January.  It will be hard to get a new hard drive that's not a 4k drive after that point.  And if unRAID doesn't move to starting at sector 64, won't we all be limited to only Western Digital drives?

[bubbaQ]

But don't only the Western Digital drives have a jumper?

 

Not necessarily.  And some drives may basically be hardwired to use the offset (i.e. no jumper on that drive will be the same as HAVING the jumper on the WD drive).  Manufacturers may do all kind of stupid crap to deal with this.  It is not just an engineering issue -- it is a brain-dead average user issue too.  They want engineering solutions to minimize returns and complaints because "my drive don't work right."

 

This points out the morass that drive manufacturing is in.  We need to take a deep breath, and give this 6 months to a year to shake out.

[prostuff1]

We need any new drives added to the array to start at sector 64 so that the jumper, wdAlign, etc are not needed.

 

First WDAlign has NO effect when a drive is used in unRAID.

 

Second, the jumper works.  Put the jumper on when you take the drive out of the package, and leave it there.  Problem solved.

 

Not to mention the risk of unintended consequences.  For example, if unRAID starts using sector 64, but you have a WDEARS drive that *has* the jumper, you will send performance into the toilet, just like starting at sector 63 with an WDEARS drive *without* the  jumper.

 

Unless there is some way to query the drive and determine the jumper status, this needs to be left alone w/r/t unRAID.  

 

It is also important to recognize scare resources, and not waste them.  unRAID development time does not need to be wasted on solving problems that are already solved.

 

 

 

I completely understand your sentiment and get what you are saying.  My only concern is that the jumper is WD only and there are other drives out/ being released (Samsung) that do not give a way to "align" the drive.

 

 

I completely understand the complexity in getting this right so that nothing breaks for existing arrays, but any new drives that are put in are formatted and set up for sector 64 start and not sector 63.  If the Drive ID can be read and a message presented to the user that they have put in a WD EARS drive and that it should/should not have a jumper on it.  Or simply ask them if it does have a jumper after they select the drive from the drop-down.  If they say "yes it does have a jumper" then set it up to start at sector 63; if they say "no it does not have a jumper" then start it at sector 64.  I understand that there are other things involved also (exposing 4K sectors etc) but I am trying to keep this short(er).

 

The more tricky part I see is when a drive rebuild needs to be done.

[reggie14]

But don't only the Western Digital drives have a jumper?

Not necessarily.  And some drives may basically be hardwired to use the offset (i.e. no jumper on that drive will be the same as HAVING the jumper on the WD drive).  Manufacturers may do all kind of stupid crap to deal with this.  It is not just an engineering issue -- it is a brain-dead average user issue too.  They want engineering solutions to minimize returns and complaints because "my drive don't work right."

 

As far as I know, the WD drives are currently the only 4k drives to have a jumper for changing alignment.  Are you suggesting that Samsung, and the other manufacturers, will come around and start including a jumper setting too?

 

This points out the morass that drive manufacturing is in.  We need to take a deep breath, and give this 6 months to a year to shake out.

 

What makes you think time is going to help?  OEMs drive the hard drive market, not people buying retail.  From an OEM perspective, it will only get easier to work with 4k drives natively, reducing the incentive for hard drives manufacturers to change products and include a jumper.  It's not like this change was all that sudden.  The move to 4k sectors has been in the works.  The industry probably should have collectively planned for the transition better while the change is happening, but I think they've been pretty clear about where they're going.  It's going to be up to software vendors, motherboard vendors, and SATA controller vendors to catch up.  And that includes unRAID.

 

Even if you're right, and there will be some movement that will make LimeTech's job easier, 6-12 months seems like a pretty long time.  And in the meantime we'd be stuck with very limited options, between the lack of 3TB support and the issues with 4k sector drives.  And I sure hope that not all paths forward involve getting new hardware.  I accept that I'll probably need a new motherboard to use 3TB drives, but I don't want to need a new board to simply use non-Western Digital drives.

 

 

[madpoet]

I have to agree, I would think the 4k drives are a far bigger issue than AFP.  I know AFP was promised for a long time and I feel for the Apple users (since, you know, they chose a Mac ) but the drive issue is only going to grow exponentially.