CHKDSK on SSD?

[nine9s]

I will build a new PC next week with my first SSD. Should you or should you not use CHKDSK on a SDD every now and then?

 

[Elixer]

Why not ?
CHKDSK is meant to find & fix problems...
You just shouldn't defrag a SSD.

 

[taltamir]

CHKDSK allows you to choose 2 procedures:
1. "Automatically fix file system errors" (FAT/NTFS file-system scan & error repair): Perfectly fine to use that to fix issues with the filesystem. (those most commonly occur when you have an improper shutdown)
2. "Scan for and attempt recovery of bad sectors": Don't use it on your SSD. (based on my understanding of SSDs and CHKDSK I believe it is bad to let CHKDSK do that to an SSD; your SSD controller is doing it internally correctly and automatically anyways)

 

[Johnny Lucky]

The answer I find over in the business enterprise side of the market is never run CHKDSK on a solid state drive. The partitioning and MTF are not the same as a standard magnetic drive.

On the gamer and enthusist side of the market it gets kind of crazy. Visit enough forums and you will see all sorts of answers and opinions. It is not unusual to see posters go off on a tangent.

 

[taltamir]

The answer I find over in the business enterprise side of the market is never run CHKDSK on a Solid State drive. The partitioning and MTF are not the same as a standard magnetic drive.

Where exactly does this business enterprise advice come from specifically? I have never heard it before and its just plain wrong.
The partitioning is determined by MBR or GPT.
The MFT (I presume that is what you mean by MTF) are 100% determined by the filesystem of choice (FAT, NTF, ext4, ZFS, etc...)

The FS does not and CANNOT know if you are using an SSD or an HDD. And is in no way affected by it.

 

[Charlie98]

It fixed my BSOD issues with my Agility3...

 

[Nothinman]

The answer I find over in the business enterprise side of the market is never run CHKDSK on a solid state drive. The partitioning and MTF are not the same as a standard magnetic drive.

On the gamer and enthusist side of the market it gets kind of crazy. Visit enough forums and you will see all sorts of answers and opinions. It is not unusual to see posters go off on a tangent.

Apparently you're looking in all of the wrong places because the filesystem is completely independent of the medium used and chkdsk is used to correct filesystem problems regardless of the device below it.

 

[Johnny Lucky]

The primary source of information is Microsoft and independent lab tests.

CHKDSK will work with an ssd but it will not produce the intended results. Here is what testing indicated will most likely happen:

CHKDSK will test 25% of the drive twice

CHKDSK will test 50% of the drive once

CHKDSK will not test 25% of the drive at all

There were a few other minor variations that came up in testing. I did not understand the technical explanations. Microsoft concluded the operating system probably would not perform a correct job so they recommended that CHKDSK not be used. Microsoft also recommended users contact ssd manufacturers regarding technical details about ssd's.

IMPORTANT - This information is from 2008. I just realised it may be ancient history. Have I missed something? Has the situation changed? I know a few ssd users are reporting issues when running Windows 7 CHKDSK.

 

[Nothinman]

The primary source of information is Microsoft and independent lab tests.

CHKDSK will work with an ssd but it will not produce the intended results. Here is what testing indicated will most likely happen:

CHKDSK will test 25% of the drive twice

CHKDSK will test 50% of the drive once

CHKDSK will not test 25% of the drive at all

There were a few other minor variations that came up in testing. I did not understand the technical explanations. Microsoft concluded the operating system probably would not perform a correct job so they recommended that CHKDSK not be used. Microsoft also recommended users contact ssd manufacturers regarding technical details about ssd's.

IMPORTANT - This information is from 2008. I just realised it may be ancient history. Have I missed something? Has the situation changed? I know a few ssd users are reporting issues when running Windows 7 CHKDSK.

I could understand if you were talking about bad block tests, but all of the filesystem data structure checks should work just fine otherwise that would mean that data written to the drive isn't always returned the same which would be worthless.

 

[Johnny Lucky]

Let's try it a different way.

What is the worst thing that can happen if chkdsk repeatedly does not test 25% of an ssd as the lab tests indicate?

 

[Coup27]

Are we not just creating problems here?

If you buy a new SSD and put it into a system and install Windows from scratch, there is no need to run CHKDSK before/during/after and there is no need to run it every month or couple of months.

If your system spanks in that way then on boot Windows will force a run of CHKDSK and you will have no choice.

 

[Nothinman]

Let's try it a different way.

What is the worst thing that can happen if chkdsk repeatedly does not test 25% of an ssd as the lab tests indicate?

Again, that can only be true for the bad block tests. There is absolutely no way that chkdsk can't check the entire logical filesystem, if that were the case Windows wouldn't be able to run either since it would be missing 25% of it's filesystem information.

 

[Johnny Lucky]

Coup27 - I am inclined to agree with you. I have not kept up with the latest developments. I simply relied on the old information and never run chkdsk on an ssd. Never experienced forced chkdsk on bootup.

Nothinman - I am inclined to agree with you too. Perhaps it only applied to bad block tests during the early days of consumer ssd's.

BTW - Several news items published during the past 24 hours indicate Microsoft will include a new and improved chkdsk in Windows 8 and server versions of the OS. Forced chkdsk on bootup will be handled differently. No more waiting.

 

[Emulex]

NTFS in windows 7 is semi self-healing. windows 8 will be even better where it can repair sections online. google ntfs versions to understand.

nothing wrong with doing a chkdsk /f on an SSD. Hell i defrag mine about once a year for shits.

 

[taltamir]

Johnny Lucky: You are not providing a link, you are saying "as far as I REMEMBER MS said such and such".

If you want to know what happens when you run CHKDSK on an SSD see

CHKDSK allows you to choose 2 procedures:
1. "Automatically fix file system errors" (FAT/NTFS file-system scan & error repair): Perfectly fine to use that to fix issues with the filesystem. (those most commonly occur when you have an improper shutdown)
2. "Scan for and attempt recovery of bad sectors": Don't use it on your SSD. (based on my understanding of SSDs and CHKDSK I believe it is bad to let CHKDSK do that to an SSD; your SSD controller is doing it internally correctly and automatically anyways)

I believe you saw a warning about #2 and misremember it to be a warning about #1

 

[Charlie98]

I believe you saw a warning about #2 and misremember it to be a warning about #1

Soooo... what would be the proper way to run CKDSK for an SSD? When I ran CKDSK on my SSD, I checked both options... it ultimately fixed the problem, but I don't want to screw myself in the long run.

 

[taltamir]

Soooo... what would be the proper way to run CKDSK for an SSD? When I ran CKDSK on my SSD, I checked both options... it ultimately fixed the problem, but I don't want to screw myself in the long run.

1. Check the box that says "Automatically fix file system errors"
2. Uncheck the box that says "Scan for and attempt recovery of bad sectors"

 

[Johnny Lucky]

taltamir - You are right. I got things mixed up. My bad!

I spent some time over at Microsoft searching for information. What I found in the Microsoft Knowledge Base were a few old recommendations indicating that chkdsk should not be used in very specific situations. For example one article indicated the old DOS and DOShell versions of chkdsk should not be used with Windows. Another article indicated chkdsk should not be run manually without specifying parameters. Yet another article indicated chkdsk should not be used if drive failure was imminent. There were a few more specific situations but nothing directly related to the topic of this thread.

 

[mv2devnull]

chkfsk is a single binary. Obviously, "old DOS" chkfsk monolith could not have contained code to operate on "new NTFS". Un*x do have separate fsck.filesystemtype binaries for each filesystemtype (ext2, ext3, ext4, xfs, jfs, ...). Un*x do have a separate "badblocks" binary too.

All unnecessary disk operations should be avoided on the imminent failure case. Treat the filesystem as read-only, read the data with one pass, and pray the drive doesn't break during that. If successful, you will have a backup copy of the data on a healthy drive. There you can try to fix filesystem errors, if necessary.

 

[Nothinman]

taltamir - You are right. I got things mixed up. My bad!

I spent some time over at Microsoft searching for information. What I found in the Microsoft Knowledge Base were a few old recommendations indicating that chkdsk should not be used in very specific situations. For example one article indicated the old DOS and DOShell versions of chkdsk should not be used with Windows. Another article indicated chkdsk should not be run manually without specifying parameters. Yet another article indicated chkdsk should not be used if drive failure was imminent. There were a few more specific situations but nothing directly related to the topic of this thread.

Sadly a lot of MS documentation seems to be written by interns that don't really know what they're talking about. Just look at the inconsistent and misuse of the term virtual memory.

But the recommendations you mention are obvious to anyone that understands how they work.

The DOS versions of chkdsk most likely assumed no other processes were running since DOS was multitasking, so if you run it while Windows was running you ran the risk of running into corruption.

Running chkdsk without parameters won't fix anything so it's fairly pointless, but wouldn't cause any harm.

Running any disk intensive task on a dying drive will lower the life of the drive even more and lower your chances of recovering the data. Your best bet is to take an image of the drive (I like dd_rescue for that) and then to try and fix the image so as to not put more load on the drive than necessary.

A bad block check on an SSD wouldn't make any sense because the firmware is supposed to manage the logical to physical mappings behind your back so you have no idea what you're really testing. It's like running it on a RAID or LVM volume. You have no idea how the controller, SAN, etc is handling all of it so you're just generating I/O for no real reason.

 

[Elixer]

The DOS version of chkdsk can only work on FAT filesystem.
If you use chkdsk launched from the cmd shell, then, that one is 100% fine to run at any time.
Heck, it is more preferred, since you have more control over the one launched via the GUI.
What I like doing is telling the system to unmount the partition, via the /x switch, and if it can't, it will tell you if you want to run chkdsk on next startup...

 

[Synomenon]

Never mind. I forgot that I asked this before and it has already been answered.

 

[bigi]

It checks file system regardless where it resides. So, yes: chkdsk drive /x/f