So...  I just replaced my parity drive with a new 4TB drive and completed the Parity Sync.  Now, Unmenu (and MyMain) reports that my last parity check was 15846 days ago.  Should I be concerned that I have an issue with my server?  At the moment I'm not too worried because parity sync completed with no errors.  How is this value calculated?

In the Web GUI, click on Settings - then Date & Time

 

What does it show for the current date & time?

 

So...  I just replaced my parity drive with a new 4TB drive and completed the Parity Sync.  Now, Unmenu (and MyMain) reports that my last parity check was 15846 days ago.  Should I be concerned that I have an issue with my server?  At the moment I'm not too worried because parity sync completed with no errors.  How is this value calculated?

You are confusing parity "sync" with parity "check"

 

You've NEVER performed a parity check.  (not with that parity drive)  You've only written parity to the parity drive.  (parity sync)

You've never verified it can be read back and validated it against the data disks.

 

0nce you do, the date will show correctly.

 

The date of the last "check" is stored as the number of seconds since the UNIX epoch, Jan 1, 1970. 

The last-parity-check-value you have on your system is "0"  (1/1/1970)

Apparently, that is 43.41 years ago.

 

You now need to perform a parity check.  Otherwise you have no idea if the parity disk was written to properly.

 

Joe L.

Hi Joe,

 

That is very interesting and makes a lot of sense.  The only thing that doesn't make sense to me is the need to do a Check after a Sync.  That, I think, is a very important bit of information that I was not aware of.  I've had my server up and running for years now and had always thought that a Sync would always result in the same security as a Check.  Thank you for the new info.

 

Now, I'll go and perform that Check!

Hi Joe,

 

That is very interesting and makes a lot of sense.  The only thing that doesn't make sense to me is the need to do a Check after a Sync.  That, I think, is a very important bit of information that I was not aware of.  I've had my server up and running for years now and had always thought that a Sync would always result in the same security as a Check.  Thank you for the new info.

 

Now, I'll go and perform that Check!

There have been plenty of times where a disk cannot be read after it is written.  It is only then (when being read) that un-readable sectors can be identified by the SMART firmware.  (A sector is considered un-readable if the checksum at the end of a sector does not match the contents of the sector.)

 

Yes, In my opinion, a parity check is very necessary after an initial parity calc.

 

Joe L.

Good explanation Joe -- I didn't realized the "Last check on ..." wouldn't simply say "Never"

 

I'm surprised the parity sync operation doesn't do a verify ... either "on the fly", or by simply initiating a check when it's done.    While I always recommend a check immediately after syncing, I agree that it shouldn't be necessary.

 

Good explanation Joe -- I didn't realized the "Last check on ..." wouldn't simply say "Never"

Neither did I. 

 

I'm surprised the parity sync operation doesn't do a verify ... either "on the fly", or by simply initiating a check when it's done. 

It should initiate a check on its own.  Might make a suggestion for an enhancement for it to do just that.

  While I always recommend a check immediately after syncing, I agree that it shouldn't be necessary.

Ah, but a check is necessary.  Otherwise the first time you might find an unreadable sector is when you are dealing with a disk failure and trying to read parity.

 

Joe L.

While I always recommend a check immediately after syncing, I agree that it shouldn't be necessary.

 

Ah, but a check is necessary.  Otherwise the first time you might find an unreadable sector is when you are dealing with a disk failure and trying to read parity.

 

I didn't mean it wasn't necessary to do the check ==> I meant it shouldn't be necessary to manually initiate it ... UnRAID should automatically do it immediately after it computes parity (or include an "on-the-fly validation of the writes) 

UnRAID should automatically do it immediately after it computes parity (or include an "on-the-fly validation of the writes) 

Immediate validation of writes is hard to do, because everything is written for speed, and cached values are returned unless you flush all the involved caches. Best to start a parity check immediately after finishing the build like your first case, that way no relevant data should be left in any of the caches. I suspect that's why Tom did it the way he did, because asking the drive to confirm it just wrote the value you told it is almost useless, so why bother coding an on the fly check. Trust but verify, in this case after a period of time and a bunch of data has passed. If Tom codes it so every time parity is fully built it goes back and checks it, the initial array time is going to get even more ridiculous, and it will only catch a very few bad cases. I think it's a case of how much hassle and time the extra data security is worth. Perhaps all that is needed is a prominent reminder in the stock GUI that shows the time since the last parity check. If never, put the reminder in all red caps. If more than 3 months, yellow caps. That way at least people can make an informed decision based on how important their data is to them.

I agree that the only real change needed is to make the "Last check on ..." say NEVER.

 

Perhaps putting NEVER is all-caps, red text would be a nice, prominent reminder to do a check 

 

... I also like the idea of displaying the time in Yellow if it's been more than 90 days (and perhaps red if more than a year).

I agree that the only real change needed is to make the "Last check on ..." say NEVER.

It will... once I finish adding that to the existing logic.

 

Perhaps putting NEVER is all-caps, red text would be a nice, prominent reminder to do a check 

I think that can be arranged.

... I also like the idea of displaying the time in Yellow if it's been more than 90 days (and perhaps red if more than a year).

The unMENU screen already does that, although with slight differences in its coloring/timing.

 

If > 90 days, the number has a [glow=red,2,300]RED[/glow] background

if > 60 days and <= 90 days, the number has a [glow=yellow,2,300]yellow[/glow] background

if > 30 days and <= 60 days, the number is bold.

If < 30 days, the number is in normal font.

 

Joe L.

The unMENU screen already does that, although with slight differences in its coloring/timing.

 

Yes, I'm well aware of that.  But not everyone uses UnMenu ...in particular those who are probably most at risk of not running parity checks