Hi all,

 

Been using unraid for years and have been very happy.  I'm currently using v4.5.6.  I have one parity and 7 drives varying between 750MB and 2TB.  Aside from reading and writing to it I don't run any special apps or anything else.

 

Is there any performance advantage (or other advantage) to upgrading to a more recent version?  (I'm not planning on adding/changing discs...)

 

Thanks!

Brian

I would say there are two benefits:

 

1) With UnRAID 5.0 you no longer need to worry about disk assignments. 5.0 doesn't care what SATA port you connect each drive to - it just reads the unique drive ID. In 4.X if you had to move disks around and screwed up the SATA connections you could have issues (i.e. if you have a motherboard failure).

2) Supportability - Far better to get yourself onto 5.0.5 in a controlled fashion while things are running smooth vs. having something horrible happen to your system and have no-one able to support you on such an ancient version.

 

You don't mention if you are running any plugins, but this will give you a chance to refresh/update those as well if they exist.

 

At this point there is 0 reasons to stick on a 4.X build and huge reasons to upgrade.

 

At this point there is 0 reasons to stick on a 4.X build and huge reasons to upgrade.

 

I disagree.  Every upgrade has risks.  If it is working, and you don't have a good reason to upgrade, you might have a valid reason to maintain the status quo.

 

That said, I think it's prudent to update.

 

 

At this point there is 0 reasons to stick on a 4.X build and huge reasons to upgrade.

 

I disagree.  Every upgrade has risks.  If it is working, and you don't have a good reason to upgrade, you might have a valid reason to maintain the status quo.

 

That said, I think it's prudent to update.

 

Yes, every upgrade has it's risks, but so does running a way out of date version of a piece of software, and you need to weigh the risks of staying where you are vs. moving forward. In this case I would think it's a no-brainer - if the OP's server were to fail and he was looking for support, running a 5.0.X build would be one of the first suggestions in order to provide adequate support. I would think having the ability to do this in a controlled fashion on a stable machine is highly preferable to trying to do this in a panic situation.

I 100% agree with your points. But there is still a reason not to upgrade. There are many organizations that run outdated software for a reason, even if you and I don't find it valid.

Hi all,

 

Been using unraid for years and have been very happy.  I'm currently using v4.5.6.  I have one parity and 7 drives varying between 750MB and 2TB.  Aside from reading and writing to it I don't run any special apps or anything else.

 

Is there any performance advantage (or other advantage) to upgrading to a more recent version?  (I'm not planning on adding/changing discs...)

 

Thanks!

Brian

 

The biggest reason to upgrade, IMO, is access to disks larger than 2T.

A few observations ...

 

Been using unraid for years and have been very happy. ...

 

Remember the old adage, "If it ain't broke, don't fix it"

 

 

Aside from reading and writing to it I don't run any special apps or anything else.

 

... with no plugins or add-ons, there's no real reason to upgrade

 

 

Is there any performance advantage (or other advantage) to upgrading to a more recent version?  (I'm not planning on adding/changing discs...)

 

Simply put:  No.

More detail:  By far the biggest advantage of upgrading to v5 is support for > 2TB disks.  Since you have no intention of moving to the larger disks, that is irrelevant in your case.    The other notable advantage, which is mentioned above, is the automatic disk assignments that v5 tracks -- so if you were to have a motherboard or disk controller failure, you could simply move all the disks to a new system and boot, without concern for disk assignments.  The latter is, however, not a big deal as long as you have a current printout of the Web GUI showing your disk assignments ... and on such a stable system I suspect you have that.

 

 

There's actually one feature in the v4 series that I like better than in v5:  it's possible to restart emhttp in v4 without a reboot; whereas in v5 that isn't possible (it generates a segfault).    This is a minor issue, but it's nice when emhttp fails to respond ... something that is rare in both versions, but does happen.

 

 

One thing I WOULD do, even if you don't want to upgrade to v5:  Upgrade to v4.7 

There were two notable changes between 4.5.6 and v.7:  (1)  Support for Advanced Format drives was added; and (b) the "Too many open files" issue when copying with Windows 7 was fixed.

 

The latter (Too many files) could be worked around in v4.5.6 by adding a line in your /boot/config/ident.cfg file to increase the ulimit value (usually "ulimit -n 20000") ... but with v4.7 this isn't needed.    The advanced format support is something that would be very useful if one of your drives fail, as it's almost certain that any new 2TB drive you buy will use advanced formatting.

 

Any upgrade has some risk, but moving from v4.5.6 to v4.7 is very simple -- you only need copy bzimage, bzroot, and memtest.    There are no syslinux changes, and no configuration changes needed (although if you have the ulimit mod in ident.cfg you can remove it).

 

I know quite a few folks who still run v4.7 on stable systems that don't need > 2TB support; and I suspect those systems will remain on that version for a long time.

 

... by the way, if you need the v4.7 download, you can request it at the bottom of the download page ["... If you require a previous release, please send a request to [email protected] "]

 

I 100% agree with your points. But there is still a reason not to upgrade. There are many organizations that run outdated software for a reason, even if you and I don't find it valid.

 

Valid arguments from both sides, I would say upgrade for support though if it is straight forward. 5.05 is the latest stable release and appears to be just that.

 

FYI sureguy I would say that large organisations run outdated software for the following reasons:

1) It costs them a fortune to upgrade

2) It costs them a fortune in licensing

3) They stick with the most stable, most supported version

4) They wait for new versions to be 'field tested' by joe public and smaller organisations before they spend a fortune on upgrading.

 

When your reasoning for an upgrade is a more stable system with better support at no extra cost any organisation would make that change.

A few observations ...

 

Been using unraid for years and have been very happy. ...

 

Remember the old adage, "If it ain't broke, don't fix it"

 

 

Aside from reading and writing to it I don't run any special apps or anything else.

 

... with no plugins or add-ons, there's no real reason to upgrade

 

 

Is there any performance advantage (or other advantage) to upgrading to a more recent version?  (I'm not planning on adding/changing discs...)

 

Simply put:  No.

 

Didn't 4.7 still contain a issue that could cause data loss? I only started on the 5.0 beta phase, but I remember seeing posts about an issue with 4.7 that was supposed to be fixed in 4.7.1 but was moved to 5.0 instead.

 

 

Didn't 4.7 still contain a issue that could cause data loss? I only started on the 5.0 beta phase, but I remember seeing posts about an issue with 4.7 that was supposed to be fixed in 4.7.1 but was moved to 5.0 instead.

Edge case only. 4.7 is extremely stable, I had no data loss and uptimes only interrupted by long power loss that the battery backup couldn't handle and drive failures. I think I had at least 2 periods of more than a year between reboots. The only reason I upgraded was for drives larger than 2TB.

... by the way, if you need the v4.7 download, you can request it at the bottom of the download page ["... If you require a previous release, please send a request to [email protected] "]

And the upgrade instructions in the readme.txt that comes with 5.0.5 download say:

If you are currently running any unRAID Server OS release before 5.0:

---------------------------------------------------------------------

 

- Please refer to upgrade instructions on our wiki:

  http://lime-technology.com/wiki/index.php/Upgrade_Instructions

And those upgrade instructions on the wiki say:

If you are currently running:

Any release before 4.7

Upgrade your server to version 4.7 and verify your server boots properly into 4.7 and your configuration appears valid.

Now follow instructions for upgrading from 4.7 in next section.

So you do need the 4.7 download.

 

You will have to upgrade twice, and the download for the first required upgrade is not available except by request. Extra hoops to jump through.

 

Another argument for staying somewhat up-to-date at least for this product. I guess you could say that 4.5.6 is officially EOL.

 

I've never used that version and I suspect many others on the forum that might potentially help in the event of any problems have not used it either, but I know there are some on the forum that have, and may even have it running on one of their older servers.

One other consideration in when to upgrade - new OS versions have support for newer motherboards and chip sets. If an old MB were to fail you might have trouble getting a new one to boot with a backlevel OS, and be looking to upgrade your MB and unRaid version at the same time. I would suggest going to 5.0.5.

Didn't 4.7 still contain a issue that could cause data loss? I only started on the 5.0 beta phase, but I remember seeing posts about an issue with 4.7 that was supposed to be fixed in 4.7.1 but was moved to 5.0 instead.

 

There are 3 known bugs in v4.7 -- the most serious is an edge case where you can, under certain circumstances, lose the data from a write to a disk during a reconstruction of that disk.  As long as you don't do that, it's not an issue.    The other bugs are even more esoteric, and less likely to cause an issue.

 

The know bug in v5.0.5 that can cause major data loss when moving data between shares (to, for example, reorganize your disks) is a FAR more serious data loss scenario.

 

 

Note that you need to upgrade to v4.7 anyway before you can upgrade to v5, so I would definitely go ahead and do that.    Whether you want to upgrade beyond that is up to you ... but quite frankly as long as you don't need > 2TB support, I'd probably just leave well enough alone.  As Jonathanm noted, v4.7 is exceptionally stable.   

 

At some point in the future, if you decide you want > 2TB support;  or if your hardware was to fail and you need to move the system to a new system; then you can upgrade to v5 (or 6) at that point.  With no add-ons to contend with, you can actually "upgrade" by simply moving the disks to a new system and creating a new config on v5.  The only important thing in that process is you need to know which disks are data and which one was your parity drive ... and you can actually determine that without any danger to your data even if you don't have them recorded.

 

 

Do you know if that issue is unique to 5.0.5 or was it introduced way before that and just never noticed? Has anyone actually done testing on 5.0 or 4.7 to see if the problem reoccurs? Given that it's a somewhat unusual situation (in my mind anyway) it may well have gone unrecorded for a long time before someone stumbled across it.

Do you know if that issue is unique to 5.0.5 or was it introduced way before that and just never noticed? Has anyone actually done testing on 5.0 or 4.7 to see if the problem reoccurs? Given that it's a somewhat unusual situation (in my mind anyway) it may well have gone unrecorded for a long time before someone stumbled across it.

 

No, I don't know.    Brian (bjp999, not BrianB) may have some idea when this bug was introduced.  I don't think it was a problem in v4.7, but anything's possible ... and without setting up a v4.7 test system and running some scenarious that are known to cause the problem in v5 it's hard to say for sure.

 

 

Do you know if that issue is unique to 5.0.5 or was it introduced way before that and just never noticed? Has anyone actually done testing on 5.0 or 4.7 to see if the problem reoccurs? Given that it's a somewhat unusual situation (in my mind anyway) it may well have gone unrecorded for a long time before someone stumbled across it.

 

No, I don't know.    Brian (bjp999, not BrianB) may have some idea when this bug was introduced.  I don't think it was a problem in v4.7, but anything's possible ... and without setting up a v4.7 test system and running some scenarious that are known to cause the problem in v5 it's hard to say for sure.

 

That was what I was thinking as well. Since no-one knew to test for this issue, no-one likely tried before 5.0.5. because it was a 5.0.5 user who accidently stumbled across this. I also doubt few of us are wanting to set up test systems to see how far back this goes.

 

My only thought is this keeps getting raised as a 5.0.5 bug when it quite likely predates that version.

My only thought is this keeps getting raised as a 5.0.5 bug when it quite likely predates that version.

 

It's not at all clear that would be true.  v5 uses a significantly different set of components, and virtually all the Linux components are different.    If I get a chance this week, I'll set up a v4.7 system; add a few shares to it; and see if the bug manifests itself.

 

Brian (bjp999):  Do you know a precise way to force the issue with v5.0.5?  I'd like to try the exact same sequence of events on both v5.0.5 and then on v4.7 to see if the bug existed "way back then".

 

... r.e. "... a precise way to force the issue ..."  ==> with as minimalistic as possible a system and set of files.    I'd like to just set up a v5.0.5 system;  add a couple shares; populate them with a few dozen files; and then do whatever is needed to cause the data loss.

 

Then repeat the exact sequence with a v4.7 setup and see if the same loss occurs.

 

Are you taking about the user share copy bug or the old rebuild bug?

 

The user share copy bug still exists and I bet goes back to the beginning. The bug is if you copy files from a disk share to a user share to which that files belong, it will try to overwrite the files and wind up truncating them in the process. So it's you have a user share called Movies, and copy files from disk1\Movies to Movies, it will try to write the files on top of themselves, and get clobbered EVEN IF disk1 is excluded from the user share in the configuration. Nasty!

 

The rebuild issue was fixed in one of the many 5.0 betas and never updated in 4.7 (despite an initial plan to do so). If I remember right, after a disk rebuild, parity would be off and if you did another rebuild, it could be slightly damaged.

 

Another reason to upgrade is it gets harder and harder to get version specific help with three old versions. Even people like me that lived this versions forget. 

First of all...Thanks for all the amazing support and comments--and to think I was wondering if I'd get a single response!

 

I sent an email to request the upgrade to 4.7.  I do have a printout of my drive locations, but the point about supporting newer drives and/or possibly an easier time upgrading should I have a motherboard or controller failure makes some sense.

 

No, I don't use any of the plug-ins.

 

It seems that people are still split on whether to go from 4.7 to 5.05 so I'll have to think about it.

 

Thanks much,

Brian

Are you taking about the user share copy bug or the old rebuild bug?

 

The user share copy bug still exists and I bet goes back to the beginning. The bug is if you copy files from a disk share to a user share to which that files belong, it will try to overwrite the files and wind up truncating them in the process. So it's you have a user share called Movies, and copy files from disk1\Movies to Movies, it will try to write the files on top of themselves, and get clobbered EVEN IF disk1 is excluded from the user share in the configuration. Nasty!

 

The rebuild issue was fixed in one of the many 5.0 betas and never updated in 4.7 (despite an initial plan to do so). If I remember right, after a disk rebuild, parity would be off and if you did another rebuild, it could be slightly damaged.

 

Another reason to upgrade is it gets harder and harder to get version specific help with three old versions. Even people like me that lived this versions forget. 

 

Ok, so it sounds like upgrading makes some sense.  I don't use user shares, so no problem there, but have already had to rebuild a disc and don't like the idea that data might be lost or corrupted.

 

B.

From the 5.0 beta8 announcement thread concerning the old rebuild / parity sync bug:

 

There's a critical bug fix in this release having to do with data rebuild.  There is a corner case that comes up where, if during a data rebuild of a disabled disk (or disk replaced with a larger one), if a write-request occurs for another disk in the same stripe for the disk currently being rebuilt, it's possible the data for the disk being rebuilt is not actually written.  Later, this will cause a Parity Check 'sync error'.

The "rebuild" bug is what I mentioned earlier as one of the 3 known bugs in v4.7.  Note that this is somewhat of an edge case ... you have to specifically write data to the disk during a drive rebuild for it to occur.  It's clearly trivial to simply not do this, and you won't get hit with it.

 

And it only impacts the single write you were doing -- no other data is harmed.  What will happen is you'll get a parity sync on the next parity check, since the parity write actually happened while the actual disk write did not.    Yes, it's not nice that it occurs ... but it's nowhere near as catastrophic as the share copy bug in v5.0.5.    The next question, of course, is if that share copy bug is indeed something that also happens in v4.7.

 

... I'll try to give a definitive answer to that in a day or two, when I get a chance to set up a test system with a few old disks and see what happens.

 

Thanks for actually testing this out Gary. I think we would all rather "know" than "assume" how large the issue is, and how far back it goes.

 

It would be interesting to test in 6.0-beta6 as well. As Brian (bjp999) mentions, it could go all the way back to the beginning, which also means it's likely still with us even in the new betas.