It assumed to be 100% safe (it's something I have tested several times yet without any issue).The difference is due the very large amount of parity bits already correct and that didn't need to be rewritten.

How faster it will be depends on the hardware configuration as far as I have experienced. E.g: if the bus/disks are slow and many data are read and written in parallel, avoiding to write will boost the process.

But here are more details provided by Brahim:

Quote

Verify & Sync can potentially be faster when:- All disk are brand new disks (no data was ever written to them)- When recomputing parity for a set of disks that used to be in an array of the exact same disk configuration (say, you deleted the old config, took some disks online, and now want to re-create the array same as it was before)

Outside of those two cases, the penalty for using Verify & Sync could be severe.

On my server, "Create-Parity" takes 9h30 for 16TB used as DRU and 2x3TB used as PPU (all DRU on one LSI controller and all PPU on another distinct LSI controller).A Verify&Sync is not faster... This is IMO logical as the PPU are on a distinct controller and are therefore not an IO bottleneck for the "Create-Parity" process...

I (believe) I understand the reasons for the performance differences between the two scenarios, but beyond the speed difference of Verify+Sync vs. Create, there's a usability difference. From the wiki:

Quote

Another purpose for this option is to delay the parity computation till after the RAID as been deployed to minimize down time. With the normal RAID initialization process, you won’t have access to your data till the parity computation is complete. In contrast, with this option, one can deploy the array making all data available right away for use (read/write) and then have the parity computation take place in the background by running the Verify/Sync task later on.

So for a large amount of data, I could see a benefit of using Create+Verify, even if it takes longer. But if you can access the data during a create/verify, why can't you do it during a create?

Here are some real world examples of doing both. tRAID1 contains 17.3TB of data out of 34.6TB and tRAID2 contains 22.5TB out of 37.3TB.

Create Parity task:

Verify & Sync:

So the throughput is higher during Create Parity task, so much so that it took 7 hours less time to complete.

Not sure why there is a throughput difference between tRaid1 and tRAID2. Both arrays have dedicated IBM 1015 controllers, identical SAS backplanes and an identical pair of PPUs (Seagate .15 4TB units).

Btw, I did the Verify & Sync tasks with both arrays online and was reading and writing data to both arrays without any issues.