Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
SSD with bad blocks??
- Thread starter Dopeyman
- Start date
- Sort by reaction score
The host never sees SSD bad blocks. Blocks of SSD memory can go bad but not in the same manner as a rotational drive, but yes gates wear out and memory pages/blocks can go bad. The SSD firmware detects these and uses spared memory pages/blocks instead. SSDs are delivered so called over-provisioned, i.e. a certain % of memory is set aside as spare. This spare memory is invisible to the host computer.
If thats what you meant...
If thats what you meant...
Well, I have a 64GB Crucial SSD in my MBP, and Drive Pulse (part of Drive Genius) gave me an error. So I took it out and connected it to my iMac to check it and defrag. It doesn't complete the task cause of an error. So I used the First Aid from the Disk Utility app and it said to format to fix. I did that and it gives an error.
So I'm thinking it has bad blocks.....
Yes, you can get bad blocks on an SSD. I've seen them come up when testing with Scannerz (see http://scsc-online.com/Scannerz.html for info.) It's up to the SSD management software to correct them, if it finds them.
Normally when an SSD is running, if it detects a bad or marginal block it's supposed to mark it as bad and replace the block with one from the over provisioned area. Detection usually occurs during a write operation and it's normal. Problems can occur when a block containing data, in other words, one that's already been written to, just goes bad. It's a sketchy situation because if the SSD takes the block out and it's in the middle of an existing file, that file will be taken out of the drive's index, essentially making it non-existent. If it leaves it in place, even though it has a bad block in it, the file remains and data can be recovered from the rest of the blocks making up the file. However, the OS will issue an I/O error during a read operation anytime it gets to that bad block, but at least some data may be recoverable.
The same dilemma exists with hard drives - what do you do with a bad block that's not being actively written to but contains data? I question whether or not an SSD will mark a block that's not being written to as bad even if it has problems. I think most are unaware of them until a write operation fails, but the firmware seems to vary considerably from manufacturer to manufacturer.
The way that's worked for me has been to do a system back up and using the manufacturers software, re-initialize the drive. It might be possible to correct the problem by using Disk Utility to re-partition the drive and use the security option to zero out all data. This might work because it might make the SSD's firmware attempt to write to the bad block and then, finally, mark it as bad and move it out of the available blocks. Of course, your SSD will be wiped clean. A simple format using Disk Utility won't work.
Dropped blocks can happen on SSDs just like they can on an HDD, and I'm not talking about HDD head crashes either. One block can just be marginal and it, for whatever reason, just goes bad. I'm actually familiar with this occurring on an iPhone that developed a bad block in the middle of a song. At the exact same point in the song, it would stop playing and iTunes would just quit. Re-iniitializing the iPhone from start and restoring the system fixed it, but that's an iPhone. There was some other post on here some time ago and the guy was having a similar problem with his SSD.
Most bad blocks on an SSD should be mapped out on detection and completely removed when the SSD gets around to doing it's house keeping. Once they've been removed, testing tools like Scannerz or Drive Genius should not be picking them up. If they are, you've got real problems - most likely you've run out of "spare's" in which case the SSD is dead.
There's no point in defragging an SSD. I doubt that would work because to defrag it, an app would have to read the bad block(s) prior to relocation which would fail, hence the operation would fail.
Normally when an SSD is running, if it detects a bad or marginal block it's supposed to mark it as bad and replace the block with one from the over provisioned area. Detection usually occurs during a write operation and it's normal. Problems can occur when a block containing data, in other words, one that's already been written to, just goes bad. It's a sketchy situation because if the SSD takes the block out and it's in the middle of an existing file, that file will be taken out of the drive's index, essentially making it non-existent. If it leaves it in place, even though it has a bad block in it, the file remains and data can be recovered from the rest of the blocks making up the file. However, the OS will issue an I/O error during a read operation anytime it gets to that bad block, but at least some data may be recoverable.
The same dilemma exists with hard drives - what do you do with a bad block that's not being actively written to but contains data? I question whether or not an SSD will mark a block that's not being written to as bad even if it has problems. I think most are unaware of them until a write operation fails, but the firmware seems to vary considerably from manufacturer to manufacturer.
The way that's worked for me has been to do a system back up and using the manufacturers software, re-initialize the drive. It might be possible to correct the problem by using Disk Utility to re-partition the drive and use the security option to zero out all data. This might work because it might make the SSD's firmware attempt to write to the bad block and then, finally, mark it as bad and move it out of the available blocks. Of course, your SSD will be wiped clean. A simple format using Disk Utility won't work.
Dropped blocks can happen on SSDs just like they can on an HDD, and I'm not talking about HDD head crashes either. One block can just be marginal and it, for whatever reason, just goes bad. I'm actually familiar with this occurring on an iPhone that developed a bad block in the middle of a song. At the exact same point in the song, it would stop playing and iTunes would just quit. Re-iniitializing the iPhone from start and restoring the system fixed it, but that's an iPhone. There was some other post on here some time ago and the guy was having a similar problem with his SSD.
Most bad blocks on an SSD should be mapped out on detection and completely removed when the SSD gets around to doing it's house keeping. Once they've been removed, testing tools like Scannerz or Drive Genius should not be picking them up. If they are, you've got real problems - most likely you've run out of "spare's" in which case the SSD is dead.
There's no point in defragging an SSD. I doubt that would work because to defrag it, an app would have to read the bad block(s) prior to relocation which would fail, hence the operation would fail.
Last edited: