Good point, I will take your vote

-dp

Essentially, yes. Validate was created well before SSD's with TRIM was invented. We have not decided whether to treat this differently or not at this time.

OK, so the "blocks updated" SoftRAID message is unrelated to genuine data in the volume, it sounds like.  And understood that SoftRAID is just in the middle.  If I'm now clear, macOS marks a block deleted on the SSD, but it isn't usable again until the SSD TRIM goes back (whenever it has quiet time to do so) and properly erases it.  So when the SoftRAID validation dialog box pops up and reports "XXXX RAID blocks which were updated", is it that SoftRAID is reporting about reconciling its knowledge of available, writable blocks with the blocks that TRIM has recently returned to service?

-dp

SoftRAID does not "perform" TRIM. It merely supports trim, which is macOS that supports it.

TRIM is when deleted blocks get changed (moved) underneath the file system. There is not supposed to be anything in those bits, so the SSD moves/deletes them. That is TRIM.

That is why a Mirror has so many blocks to update. Yes your volume would be OK, with a failover.

@dpz

There is no problem, this is an artifact of TRIM. Flash drives are constantly updating blocks in the background, (Trimming) so on any flash media, you will never see 0 blocks validated. It is a function of how flash media works.

eing @dpz

There is no problem, but what you are seeing is a side effect of SSD's with TRIM. The drives are constantly updating blocks (in the background, so they will never show 0 updated blocks when validating.

Thanks, @softraid-support.  I've been doing a fair amount of searching on TRIM and SSD garbage collection – https://www.crucial.com/articles/about-ssd/what-is-trim seems to be a pretty good high-level article on them.  However, I still don't understand the link between the garbage collection (which appears to be happening outside the knowledge of SoftRAID) and TRIM (which appears to be SoftRAID-managed).  So I have a few more questions.

• Can you more specifically follow (describe) the breadcrumbs  between a SoftRAID RAID 10 "There were 4,425 RAID blocks which were updated." alert and the AGC going on under the hood?
• Were these block updates that would have otherwise been eventually resolved by SoftRAID automatically?
• If there were 4,425 RAID blocks which needed to be updated, but one of my SSDs failed before they were, would I have failed over to the mirror disk with my data intact?

Appreciate your patience.

-dp

There is no problem, but what you are seeing is a side effect of SSD's with TRIM. The drives are constantly updating blocks (in the background, so they will never show 0 updated blocks when validating.

There is no problem, this is an artifact of TRIM. Flash drives are constantly updating blocks in the background, (Trimming) so on any flash media, you will never see 0 blocks validated. It is a function of how flash media works.

I know this is a bit old of a thread, but seems the right one to ask a followup on this topic.

I've been going 'round with OWC Support about my RAID 10 volume never appearing to be stable.  Every time I run a validation, 9/10 times there are RAID blocks updated — 10s, 100s, 1000s — even in multiple successive validations.  The volume is a 2TB stripe of 4 mirror pairs of 512GB Samsung SSD 970 PRO blades, with the mirror pairs split across two Sonnet M.2 4x4 PCIe cards.  On any given day, this volume doesn't seem to give me actual problems.

However I worry that the mirror pairs aren't in tight sync, and if I lose a blade, the mirrored blade's data won't actually be a complete replicate.  I don't remember having these volume validation issues on my old SoftRAID setup, which was a ThunderBay 4 with a RAID 4 or RAID 5 of 4 1.0TB OWC Mercury Electra 6G SSD drives.  Is it possible that TRIM is entirely the difference here?  Or am I looking at something more esoteric?

I get this behavior on both SoftRAID 6.0.5 and (installed today) 6.1.

-dp