1st validate on new...
 
Notifications
Clear all

1st validate on new volume - LOTS of updated blocks

17 Posts
3 Users
1 Likes
12.3 K Views
(@mustgroove)
Posts: 24
Member
Topic starter
 

Just wanted double check this:

1) I set up a new RAID 1+0 volume with the SoftRaid Easy Setup app. It has 4 discs - the 2 primary discs are SSDs, the 2 secondary discs are HDDs. In the Easy Setup app I chose "Digital Audio" for the volume optimisation, and it set a stripe size of 128KB.

2) I coped my data back onto the new volume

3) I validated the new volume overnight. When it was done, it had updated 175,753,559 blocks.

This seems super high - is there anything to be concerned about here? Why would so many blocks need updating when all I've done is just copy my data back to the volume?

I've just started another validation (which should surely result in zero updated blocks) and it's already updated 766.

My previous experience with SoftRaid has been a RAID 5 volume I used for years and years, and the first time I verified it I think the number of blocks that were updated was in the single digits, and then every subsequent validation (every few months) would end up with 0 updated blocks, so this is unusual from my experience.

 
Posted : 12/03/2018 10:51 am
(@softraid-support)
Posts: 8049
Member Admin
 

The first time you validate, expect lots of updated sectors - normal.

The next time, you will get zero. Unless you have SSD drives, with TRIM enabled, which I suspect you have.

This is normal for SSD's with TRIM enabled, TRIM is always changing blocks in the background to keep the SSD write performance up.

 
Posted : 12/03/2018 12:22 pm
(@mustgroove)
Posts: 24
Member
Topic starter
 

The first time you validate, expect lots of updated sectors - normal.

The next time, you will get zero. Unless you have SSD drives, with TRIM enabled, which I suspect you have.

This is normal for SSD's with TRIM enabled, TRIM is always changing blocks in the background to keep the SSD write performance up.

Yep TRIM is enabled on the SSDs. Would this ever be a problem? If TRIM is always causing changes that the mirror discs might not have caught up to, is that a possible issue in the event that an SSD fails?

 
Posted : 12/03/2018 12:40 pm
(@softraid-support)
Posts: 8049
Member Admin
 

TRIM is always updating sectors when the disk is inactive. What it effectively does is relocate and "erase" sectors, so the drive is faster when it is time to write data. (An SSD is relatively slow to "re-write" a sector)

SoftRAID is comparing raw data in every sector, so of course when SSD's TRIM, that causes the validation to show differences.

Validate will always show differences with SSD's.

Note:SSD's with TRIM enabled are extremely difficult to perform low level data recovery on if they fail. So backups are critically important.

 
Posted : 13/03/2018 1:24 pm
(@mustgroove)
Posts: 24
Member
Topic starter
 

TRIM is always updating sectors when the disk is inactive. What it effectively does is relocate and "erase" sectors, so the drive is faster when it is time to write data. (An SSD is relatively slow to "re-write" a sector)

SoftRAID is comparing raw data in every sector, so of course when SSD's TRIM, that causes the validation to show differences.

Validate will always show differences with SSD's.

Note:SSD's with TRIM enabled are extremely difficult to perform low level data recovery on if they fail. So backups are critically important.

Thanks for that - so does this potentially create problems when a disc fails? Is it better from a data safety point of view to have TRIM disabled?

 
Posted : 13/03/2018 2:21 pm
(@softraid-support)
Posts: 8049
Member Admin
 

TRIM is generally better enabled.

If you have a total disk failure, TRIM SSD's are very difficult to recover from. More than a normal SSD, which are more difficult than a HDD. Just stay backed up!

 
Posted : 13/03/2018 5:09 pm
(@mustgroove)
Posts: 24
Member
Topic starter
 

TRIM is generally better enabled.

If you have a total disk failure, TRIM SSD's are very difficult to recover from. More than a normal SSD, which are more difficult than a HDD. Just stay backed up!

Even SSDs in a RAID? So in the event an SSD dies for whatever reason, the array wouldn't just rebuild like it would with HDDs?

Had no idea this was the case, I thought RAID arrays coped with the failure of HDDs and SSDs equally well.

 
Posted : 13/03/2018 6:00 pm
(@softraid-support)
Posts: 8049
Member Admin
 

No, sorry, you are over-thinking. This does not refer to RAID, just to low level data recovery services, such as what Drive Savers.

When a HDD fails, they can often mechanically recover the data in a clean room.

TRIM enabled SSD's make it extremely difficult to do such recovery.

 
Posted : 14/03/2018 12:26 pm
(@dpz)
Posts: 13
Member
 

@softraid-support

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

 
Posted : 09/10/2021 3:29 pm
(@softraid-support)
Posts: 8049
Member Admin
 

@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.

 
Posted : 10/10/2021 2:52 pm
(@softraid-support)
Posts: 8049
Member Admin
 

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.

 
Posted : 10/10/2021 2:56 pm
(@dpz)
Posts: 13
Member
 
Posted by: @softraid-support

@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

 
Posted : 11/10/2021 9:04 pm
(@softraid-support)
Posts: 8049
Member Admin
 

@dpz

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.

 
Posted : 11/10/2021 10:15 pm
(@dpz)
Posts: 13
Member
 

@softraid-support

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

 
Posted : 14/10/2021 11:18 pm
(@softraid-support)
Posts: 8049
Member Admin
 

@dpz

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.

 
Posted : 15/10/2021 12:09 am
Page 1 / 2
Share:
close
open