why not always use "Verify Sync" instead of verify/verify+?

[gwpt]

I trying to understand why I would ever do  normal verify/verify+?

if they fail, I need to do a verify sync anyway, so why not just do the verify sync to start with?
(I assume if there are no errors it's like doing a verify.)

Doing this would half the drive wear in the case of any errors.
Am i missing something?

[Brahim]

A sync blindly updates the parity. You are supposed to analyze the state of your RAID and determine that no data disk is negatively affected before doing a sync.

[Skirge01]

As Brahim said, you should know what's going on with your array.  To expand on that a little, if you just do a verify sync, then you have no idea what was updated.  If it's not updated, you can use the Forensics plugin to see exactly what data is incorrect.  Why would you want to know what was updated?  If the same drive was constantly having to be updated, you may have a controller, cable or drive which is failing.  If the exact same data was constantly being updated, there could also be an issue with a program, your OS, or the parity drive.  If different data is constantly being updated, you may even have a memory issue.  If that's the cause, every write to your array could be bad data due to memory corruption.  Then, it's possible you'd come back here screaming that tRAID was destroying all your data.

Brahim would be better suited to speaking to this part, but I suspect that if updates are constantly necessary, the salt level might need to be adjusted, as well.  I'm basing this off the text pop-up for the salt setting, but I'm not certain I fully understand what it's really talking about.

[Brahim]

As Brahim said, you should know what's going on with your array.  To expand on that a little, if you just do a verify sync, then you have no idea what was updated.  If it's not updated, you can use the Forensics plugin to see exactly what data is incorrect.  Why would you want to know what was updated?  If the same drive was constantly having to be updated, you may have a controller, cable or drive which is failing.  If the exact same data was constantly being updated, there could also be an issue with a program, your OS, or the parity drive.  If different data is constantly being updated, you may even have a memory issue.  If that's the cause, every write to your array could be bad data due to memory corruption.  Then, it's possible you'd come back here screaming that tRAID was destroying all your data.

Brahim would be better suited to speaking to this part, but I suspect that if updates are constantly necessary, the salt level might need to be adjusted, as well.  I'm basing this off the text pop-up for the salt setting, but I'm not certain I fully understand what it's really talking about.

+1

Re: CQ Salt
I typically prefer not to get too technical in providing answers, but I do make exceptions from time to time based on who I am replying to.
The CQ salt (Concurrency Queuing salt) is kind of a fine tuning nob to an algorithm that manages concurrent elements that have different response time - in our case, different drives with different performance, access time, and random hiccups. The goal is to let things run concurrently without locks but without them colliding.
If the salt is too low, you may experience parity blocks going out of sync due to collision. If too high, it will result in performance issues and hiccups.

So, the first thing to do when there is parity block going out of sync is to check the event viewer (if on Windows) or the kernel logs (if on Linux). Those logs will have clues if I/O issues are encountered. The goal is to rule out all hardware and driver issues before looking into the CQ salt.

If no issue there, then play with the CQ salt by increasing it a bit. Increasing the CQ salt while having hardware issues will only exacerbate things.
If doubling the CQ salt from the default still does not help, then you can be sure the issue is hardware related.

[gwpt]

Thanks for the detailed response. Makes a lot for sense now.
I didn't know about the forensic plugin. I will certainly check that out too.