unRAID Server Release 5.0 i386 Available


limetech

Recommended Posts

Upgraded from 4.7 with no issues!

This is good to hear.  One reason for feet dragging lately is the realization that there may be many people upgrading from 4.7 to 5.0 all at once & if I overlooked something stupid, or there was some other Big Issue then I would be swamped with angry email.  So far so good though  ;)

Link to comment
  • Replies 345
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Upgraded from 4.7 with no issues!

This is good to hear.  One reason for feet dragging lately is the realization that there may be many people upgrading from 4.7 to 5.0

 

Good call - I'm one of those holdouts.  Probably will install sometime in the next couple of days.  Looking forward to using the 3TB drives I bought a while ago.  Going to do:

  • parity check pre-upgrade (no correct)
  • post-upgrade (no correct)
  • install the 3TB parity drive
  • rebuild the parity
  • do a parity check (no correct)
  • swap one of my 2TB drives for a 3TB drive
  • rebuild the data on the 3TB drive

 

(I'm out of SATA ports until I buy one of those SuperMicro boards, which I can and will do...  Actually maybe I should buy a 4TB parity drive, and a SuperMicro SATA board, and add those two 3TB drives to my array that way)

 

On that subject - can anyone comment on how the AOC-SAT2-MV8 is functioning with V5?

Link to comment

Good call - I'm one of those holdouts.  Probably will install sometime in the next couple of days.  Looking forward to using the 3TB drives I bought a while ago.  Going to do:

  • parity check pre-upgrade (no correct)
  • post-upgrade (no correct)
  • install the 3TB parity drive
  • rebuild the parity
  • do a parity check (no correct)
  • swap one of my 2TB drives for a 3TB drive
  • rebuild the data on the 3TB drive

 

I'd do a correcting parity check -- you want parity to be correct before you do the upgrade !!    If you're concerned about what it might correct, do a no-correct first; and then just run the correct if you have sync errors.

 

Since you're planning to immediately upgrade to a larger parity drive, I'd simply "start from scratch" with v5.  i.e. redo your flash drive for v5;  boot to it;  add all the data drives;  then add your NEW (larger) parity drive -- no need to ever assign your old parity drive.    Then start the array and let it build parity.  After that completes, run a parity check (to be sure all's okay);  and then do the 3TB drive swap.

 

Link to comment

I'd do a correcting parity check -- you want parity to be correct before you do the upgrade !!    If you're concerned about what it might correct, do a no-correct first; and then just run the correct if you have sync errors.

 

Sorry - yes, a non-correcting to verify integrity...  If an error is found, examine the file with the error to determine if it is a defect on the parity drive or the data drive, and take the appropriate action...

Link to comment

I'd do a correcting parity check -- you want parity to be correct before you do the upgrade !!    If you're concerned about what it might correct, do a no-correct first; and then just run the correct if you have sync errors.

 

Sorry - yes, a non-correcting to verify integrity...  If an error is found, examine the file with the error to determine if it is a defect on the parity drive or the data drive, and take the appropriate action...

Yeah, but you have no way of knowing that.  Let's say cosmic rays flipped one bit on one of your disks.  With single-parity setup you can only detect the existence of a parity error, but you have no way of knowing which disk it came from.  So unless you keep separate checksums for everything (which could have been the case if we were using ZFS instead of reiserfs), you'll probably just go ahead and run unRAID's parity check-correct.  It will assume that the error came from the parity disk, when with greater probability it came from the data disks.  Thus it will make a "correcting" modification to the parity disk, which will in effect make the damage permanent.

 

 

Link to comment

I'd do a correcting parity check -- you want parity to be correct before you do the upgrade !!    If you're concerned about what it might correct, do a no-correct first; and then just run the correct if you have sync errors.

 

Sorry - yes, a non-correcting to verify integrity...  If an error is found, examine the file with the error to determine if it is a defect on the parity drive or the data drive, and take the appropriate action...

Yeah, but you have no way of knowing that.  Let's say cosmic rays flipped one bit on one of your disks.  With single-parity setup you can only detect the existence of a parity error, but you have no way of knowing which disk it came from.  So unless you keep separate checksums for everything (which could have been the case if we were using ZFS instead of reiserfs), you'll probably just go ahead and run unRAID's parity check-correct.  It will assume that the error came from the parity disk, when with greater probability it came from the data disks.  Thus it will make a "correcting" modification to the parity disk, which will in effect make the damage permanent.

 

Of course you can confirm that -- all you have to do is compare the file on UnRAID with your backups.

 

In the absence of a backup, there's still a very good indicator of whether it's a data disk or parity disk error -- just see if the error column has reported errors for any data disk.  If so, it's likely the error was on the data disk;  if there are no errors reported, it's VERY likely it was simply an error in the parity bit.  There are several scenarios where the UnRAID parity disk doesn't get properly updated -- most related to improper shutdowns and/or power failures.  That's why limetech's parity check always assumes any sync errors are on the parity disk -- because in almost every case they are.

 

In ~ 5 years of using UnRAID, EVERY sync error I've ever seen (granted, a small sample -- probably 4 or 5), has been on the parity disk.    I've run complete compares against my backups in every case just to be sure ... and have NEVER had a data error.

 

 

 

Link to comment

Hey Tom any idea why when I run the upgrade util for the GUI it seems to run a script on that page, but when I go to the flash drive the "webGui-latest.plg" is 0 kB and it's the only file in that folder?

 

Edit: Running the v 5.0 release

 

I had the same issue. I use unodns and my subscription had run out so maybe check your DNS settings.

 

Now able to download the webgui without a problem

 

Need an update to the plex app urgently though!

Link to comment

I am finding two things pretty amazing:

 

1. How few problems are people reported

2. How many people decided to install an RC and then not keep it patched

 

#1 is even more amazing given #2

 

I haven't upgraded yet (still on 4.7) so some problems may still be reported! I don't expect there to be any problems but you never know. :)

Link to comment

I am finding two things pretty amazing:

 

1. How few problems are people reported

2. How many people decided to install an RC and then not keep it patched

 

#1 is even more amazing given #2

 

what is so amazing?

I am still running 5.0 Beta 13 (NOTE: BETA) and have been running for 2 years straight.

no issues what so ever

Link to comment

I am finding two things pretty amazing:

 

1. How few problems are people reported

2. How many people decided to install an RC and then not keep it patched

 

#1 is even more amazing given #2

 

what is so amazing?

I am still running 5.0 Beta 13 (NOTE: BETA) and have been running for 2 years straight.

no issues what so ever

 

If you don't know why I cant explain it to you :)

Link to comment

I am finding two things pretty amazing:

 

1. How few problems are people reported

2. How many people decided to install an RC and then not keep it patched

 

#1 is even more amazing given #2

 

what is so amazing?

I am still running 5.0 Beta 13 (NOTE: BETA) and have been running for 2 years straight.

no issues what so ever

 

My friend is the same as you. "I only need 3TB support, it's working fine, I have no reason to upgrade past this beta version...". He the guy who never upgrades any of his programs if he's not having issues, "if it's not broke don't fix it".

 

Well 5.0 final came out, I upgrade both my servers from RC15. No issues whatsoever, headache free, took 5 minutes for 2 servers. He upgrades from his older version, and I end up on the phone with him for no less than 6 hours troubleshooting the upgrade. What was the problem? Well it seems the Sabnzbd plugin, for whatever reason, didn't like one of the many changes and kept hanging his entire array. However, I use the exact same Sabnzbd version and had no problems with the upgrade.

 

You have a much larger chance of having issues when upgrading from a very old beta build, than you do just upgrading when new builds come out.

Link to comment

I had the same issue. I use unodns and my subscription had run out so maybe check your DNS settings.

 

Would that matter if I'm not running anything like unodns and I'm inside the US? And when you updated the GUI did you just click the update button and then BOOM did it just change instantly? or do I have to reset my server?

Link to comment

I am finding two things pretty amazing:

 

1. How few problems are people reported

2. How many people decided to install an RC and then not keep it patched

 

#1 is even more amazing given #2

 

what is so amazing?

I am still running 5.0 Beta 13 (NOTE: BETA) and have been running for 2 years straight.

no issues what so ever

 

If you don't know why I cant explain it to you :)

 

as my experience show, if you can't explain it to me there is at least 100 reason for it .

one you are an idiot

two I am an idiot (yes this is #2, deal with it  :-P )

three it's not important enough to warrant or understand  an explanation

four read # one 

 

:-D

 

 

"There are only 10 types of people in the world: those who understand binary, and those who don't."

 

 

PS: no offense was meant by the above post. all was in a good humor only...

Link to comment

I read both, and thought the response from garycase was appropriate

There's faulty logic in it:  Mentioning how many years he's been usung unRAID is somehow supposed to be a proof that what he's saying is correct.  The fact remains:  Simple parity code can only detect an odd number of bits in error. It cannot detect the position of the error, therefore it cannot correct errors.

 

http://www.raid-recovery-guide.com/raid5-write-hole.aspx

 

 

Link to comment

I am finding two things pretty amazing:

 

1. How few problems are people reported

2. How many people decided to install an RC and then not keep it patched

 

#1 is even more amazing given #2

 

Speaking for myself on #2, I don't want to beta test, but I required support for current hard drives, so I had to either use a 5.0 beta release or abandon UnRAID.    The RC I'm using has been working without issues and every later RC I considered updating to had reports of issues, some even data loss.  I have followed every beta release thread and tried to understand if it is better or worse than what I was already running.  Again, I'm not interested in beta testing and don't want to be the one to find a big data loss oops in an RC.

 

Even now, I'm waiting to see if 5.0 "final" has any major issues.  I don't want to update to 5.0 final and then have a 5.0a to evaluate a couple of days later!

Link to comment

I read both, and thought the response from garycase was appropriate

There's faulty logic in it:  Mentioning how many years he's been usung unRAID is somehow supposed to be a proof that what he's saying is correct.  The fact remains:  Simple parity code can only detect an odd number of bits in error. It cannot detect the position of the error, therefore it cannot correct errors.

 

http://www.raid-recovery-guide.com/raid5-write-hole.aspx

 

Garycase said exactly the same. You can use existing backups (as him) or md5/crc hashes (as I'm doing) to detect the actual data error.

 

Bases on both Garycase and my own experience, whenever there were errors during the parity (correct) sysc, the errors always was in the parity information.

 

The 'errors' from the main unraid interface only detects errors during read/write, and not perse the example you gave where a bit just changes value without writing/reading it. But your hdd also stores a crc for each sector and will throw a crc error when such a sector is accessed (and thereby also have unraid show an error).

 

From what I know, in this case (hdd throws a read error), unraid will automatically try to reconstruct the sector from parity and write it again. If writing then fails, the drive will be redballed, if the write succeeds (because the sector is fine, or the hdd remaps it) everything is ok again.

 

Only question for me is if the 'read which causes the correct' is also triggered during a parity (correct) sync....

Link to comment

syslog without any plugin

 

Total size:	2 TB	
Current position:	2.26 GB (0.1 %)	
Estimated speed:	26.8 MB/sec	
Estimated finish:	20 hours, 41 minutes

 

This was the result :(

 

Last checked on Fri Aug 30 11:58:44 2013 CEST (today), finding 0 errors. 
> Duration: 14 hours, 21 minutes, 12 seconds. Average speed: 38.7 MB/sec

 

Earlier release was this process around 9 hours with speed around 70MB/sec , 

 

Link to comment
Guest
This topic is now closed to further replies.