any point of chkdsk/r on SSD?

[tommo123]

every 6 months i do a full surface scan on my HDDs but not sure what to do with my SSDs.

i don't have any reasons to think there's a problem but for peace of mind i'd like to do this but have doubts it does anything really due to wear levelling etc.

 

[Insert_Nickname]

every 6 months i do a full surface scan on my HDDs but not sure what to do with my SSDs.

Since there isn't a recording surface on an SSD, doing that is redundant. There is simply no need.

i don't have any reasons to think there's a problem but for peace of mind i'd like to do this but have doubts it does anything really due to wear levelling etc.

File systems can, and do, go bad. Though it happens very rarely, unless there is malicious intent and/or software involved. Everything has become a whole lot more reliable in the last 20 years. A scan once in a while is a good idea, about every 6-12 months sound about right. You're not triggering anything wear levelling related, that's only when you write to the disk.

 

[tommo123]

i've never done this to an SSD, only HDDs. for SSDs i've only ever done the usual chkdsk/f.

just wasn't sure it was worth the downtime to even bother with doing a chkdsk/r on an SSD is all since i'd have to reboot which annoys me.

 

[Billy Tallis]

It is possible for data stored on a SSD to degrade. Reading all the data on the drive will give the SSD the chance to notice that and re-write any data that needed to go through the error correction process in order to be correctly read. Reading data too often can induce a read disturb error, so there's no benefit to scanning the unused/unallocated blocks of the drive, and there's no benefit to doing it more often than every few months unless your drive is close to exhausting its wear endurance.

 

[C1]

For me the value of running a simple "chkdsk" is to ensure that the file records match to what MFT has.

At least with a spinner, once in a blue moon there will become a mis-match and when that happens, the OS will run, but disk access then is noticeably slow.

"Chkdsk" is able to resolve such mis-match after which speed of access becomes noticeably improved.

Dont see why this wouldn't also be true for an SSD.

 

[BonzaiDuck]

For me the value of running a simple "chkdsk" is to ensure that the file records match to what MFT has.

At least with a spinner, once in a blue moon there will become a mis-match and when that happens, the OS will run, but disk access then is noticeably slow.

"Chkdsk" is able to resolve such mis-match after which speed of access becomes noticeably improved.

Dont see why this wouldn't also be true for an SSD.

There are any number of reasons other than hardware defect that can cause a BSOD, or simply a crash. This in turn offers the possibility of disk corruption -- spinner or SSD, either one.

I will run CHKDSK from time to time, just to assure myself. Yes -- on my SSDs, including the boot-drive NVME.

 

[IntelUser2000]

i don't have any reasons to think there's a problem but for peace of mind i'd like to do this but have doubts it does anything really due to wear levelling etc.

Wear levelling has NOTHING to do with this.

 

[CakeMonster]

Don't Win7/10 do this kind of check on a schedule?

 

[Insert_Nickname]

It is possible for data stored on a SSD to degrade. Reading all the data on the drive will give the SSD the chance to notice that and re-write any data that needed to go through the error correction process in order to be correctly read. Reading data too often can induce a read disturb error, so there's no benefit to scanning the unused/unallocated blocks of the drive, and there's no benefit to doing it more often than every few months unless your drive is close to exhausting its wear endurance.

If you just use the drive normally, data will be refreshed from time to time due to wear levelling. The controller will automatically shuffle all cells though so they're all written to. That's exactly what wear levelling is. Making sure all block are written to before you write the first ones again.

Data on an SSD is dynamic, not static.

Anand himself did some very nice articles on things once upon a time. Highly recommended reading:

https://www.anandtech.com/show/2738
https://www.anandtech.com/show/2829

 

[mikeymikec]

Don't Win7/10 do this kind of check on a schedule?

Windows 8.x and 10 do minor file system checks on a schedule, but not to the level of chkdsk /r.

chkdsk /f will fix errors that a quick chkdsk (the read-only one that occurs when you run it without command switches) can find (but it's data-orientated only), however /r checks the entire usable capacity of the drive (excluding the drive's reserve as that's not visible to the OS).

I don't know for a fact which type of check 8x and 10 do on a schedule, but if I had to bet I'd say it's chkdsk /f.



IMO I very much doubt that any of us have considerable experience with the various ways that SSDs can fail (I have personal experience of a grand total of two), and given that chkdsk /r is the most thorough file system checking tool in Windows, I'm all for running it from time to time and checking the results as part of trying to keep an eye on fixed storage. Of those of us who have considerable experience with seeing HDDs fail, I'm sure that we'll all agree that sometimes it's Windows that catches a drive failure in progress, sometimes SMART does, sometimes neither do. I see no reason to expect that to continue with SSDs.

 

[IntelUser2000]

SSDs can and do fail. Just like CPU and Memory can fail. SSDs have a wear-based failure which is basically a secondary mode of failure, but most users won't see that.

There's also a difference between a hardware failure and a software failure. File system corruption exist, and that's what chkdsk is for, and equally applies to HDDs and SSDs. You could have a rock solid disk but still need to run chkdsk /f from time to time.

 

[Insert_Nickname]

SSDs can and do fail. Just like CPU and Memory can fail.

Worse, they tend to fail spectacularly. Either they work, or they don't. There isn't much middle ground. Unlike a HDD were you at least have a chance of getting data off a failing drive.

I've had 3(?) SSD failures over the last 10 years to that tune. HDDs have been at least 20 in the same interval. Granted it's not a large sample size, but SSDs seem quite reliable to me.

 

[tommo123]

There are any number of reasons other than hardware defect that can cause a BSOD, or simply a crash. This in turn offers the possibility of disk corruption -- spinner or SSD, either one.

I will run CHKDSK from time to time, just to assure myself. Yes -- on my SSDs, including the boot-drive NVME.

just a /f or a /r ?

 

[BonzaiDuck]

just a /f or a /r ?

Actually, I just run it through the <disk:> -> "Properties" ->"Tools" -> "Check" GUI, unless there's a real problem.

Amazing that I was once a DOS whiz, and I now have to review the CHKDSK syntax to tweak it in detail. Generally, just using the GUI has repaired everything necessary as I can determine of the boot drive requires a restart to execute it.

 

[tommo123]

Actually, I just run it through the <disk:> -> "Properties" ->"Tools" -> "Check" GUI, unless there's a real problem.

Amazing that I was once a DOS whiz, and I now have to review the CHKDSK syntax to tweak it in detail. Generally, just using the GUI has repaired everything necessary as I can determine of the boot drive requires a restart to execute it.

i miss the old GUI from the win95 days where you could select multiple disks at once

 

[IntelUser2000]

Worse, they tend to fail spectacularly. Either they work, or they don't. There isn't much middle ground. Unlike a HDD were you at least have a chance of getting data off a failing drive.

I can vouch for that. HDDs fail gradually over time. Slowing performance, more errors. But still can be worked upon.

 

[BonzaiDuck]

i miss the old GUI from the win95 days where you could select multiple disks at once

It wasn't the first time since I started using Win 10, but I just noticed again that you don't have the option to specify the physical repair of sectors on the disk in addition to the files and indexes. I'll worry later about a command-line syntax in CMD or Powershell or however you would execute it, but if I never come up with errors that cannot be fixed in the GUI, that's not something I'm worried about at the moment.