jhdeerslayer Posted March 20, 2013 Share Posted March 20, 2013 I got a BSOD some time ago on this drive and ever since I run chkdsk /b to check/fix damaged blocks. Chkdsk /b resets the damaged block count and then tags again the bad ones. I run it on a weekly basis and have noticed the final "bad block" count after chkdsk /b can vary from 72k to 608k over the last month or so. My PC is running fine for now but this variation seems strange to me. The industry seems to say some small % of damaged blocks for SSD's are "normal" and I can accept that (maybe) but this variation seems odd and at what point should I worry. This is actually my second drive of this type as my first failed within a month and the PC vendor replaced it. This second drive then is about 2 months old but started showing damaged blocks within the first week of usage. Also, this whole SSD subject of damaged blocks, chkdsk usage, etc. seems to have no consensus in the industry. Link to comment Share on other sites More sharing options...
jhdeerslayer Posted March 27, 2013 Author Share Posted March 27, 2013 No thoughts anybody on this variation? It seems stable now at 600k bad clusters but the whole concept of variation seems strange to me. Link to comment Share on other sites More sharing options...
LuckyDuck69 Posted April 4, 2013 Share Posted April 4, 2013 what are you talking about? Link to comment Share on other sites More sharing options...
jhdeerslayer Posted April 4, 2013 Author Share Posted April 4, 2013 Basically as I have been running Chkdsk /b over a period of months I see variation in the number of bad clusters it tags anywhere from 72k to 608k. Seems odd so wondered. PC runs fine. Link to comment Share on other sites More sharing options...
Nec_V20 Posted April 5, 2013 Share Posted April 5, 2013 I think the problem is that you are running it with the /b parameter and you have to reboot. The TRIM function will only work with regard to a running Windows system however to do the /b you have to reboot and that reboot reflects the amount of "bad" clusters before the new boot of Windows clears it up, from the previous shutdown. Clusters will be marked "bad" because the data that was formerly there is now written to another area of the SSD however the chkdsk/b command runs before Windows is loaded to clear up the "bad" clusters using TRIM. So actually it is not a bug but a "feature". Link to comment Share on other sites More sharing options...
jhdeerslayer Posted April 5, 2013 Author Share Posted April 5, 2013 I think the problem is that you are running it with the /b parameter and you have to reboot. The TRIM function will only work with regard to a running Windows system however to do the /b you have to reboot and that reboot reflects the amount of "bad" clusters before the new boot of Windows clears it up, from the previous shutdown. Clusters will be marked "bad" because the data that was formerly there is now written to another area of the SSD however the chkdsk/b command runs before Windows is loaded to clear up the "bad" clusters using TRIM. So actually it is not a bug but a "feature". Ah ok interesting and thanks. Link to comment Share on other sites More sharing options...
Nec_V20 Posted April 5, 2013 Share Posted April 5, 2013 Chkdsk is designed to work with harddrives and SSDs work completely differently and pretend to be harddrives. I bet when you run chkdsk normally it will come up with zero errors. But yes, I agree it can be very disconcerting when one is being conscientious and meticulous and one gets rewarded with such an error message. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.