Now we're disagreeing with how secure erase affects the bad block list, so let's ignore that for a second. Before you mentioned that you ran a secure erase, then a surface check test, then checked the SMART logs. Now, there's a bit of a conflict with what you said here. This genuinely conflicts with what I understand and am trying to understand if I'm misinformed. Like I said, I've been doing this for years and years, and you can check the reallocated sector amount before and after running secure erase to verify this.īefore I continue I just want to say one thing: I'm not disagreeing with you to be a smartass or a know it all. It actually does, and the reason why it's faster is because it doesn't shuffle any data back to the system - the whole operation is done purely by the drive's own controller and firmware.
The drive places the head at the very beginning of the platter, and then just starts writing 0's.ĮDIT: Likely it's the Surface Test that's what actually marks the the blocks as bad. This is actually why Secure Erase is so much faster than simply formatting the drive. Secure erase does nothing with the bad block list. The entire purpose of Secure Erase was to ensure that EVERY single sector on the drive is 0'd out, even if it's been relocated to the bad block list. So whenever you'd try to erase all the blocks, the original block would stay unchanged, and the reallocated sector would be the one that's cleared. When a sector is added to the bad block list, the original block is not 0'd out. Secure erase won't mark the sector as bad. (I often do this process to recover older disks) If you do decide to do this, I'd also recommend running SMART surface-area selftest afterwards and checking the SMART log, whether the test completed succesfully or not - if it did, then secure erase managed to successfully reallocate those sectors. booting Linux from a USB-stick and performing it there with hdparm is probably the easiest way. There are multiple utilities for that, but e.g. If you don't wish to go that route, an way of forcing the disk's firmware to mark the sector bad and allocate another one from the spare-area is to perform ATA Secure Erase on it. If it's a brand new drive with bad sectors, I'd RMA it immediately. Any advice would be appreciated.Įdited by Calum, 24 October 2011 - 07:16 AM.CRC-error means that there are bad sectors on the disk. Is there a solution to this problem? Can the data from the older style of disks still be copied somehow? I find it strange how the error appears when copying from one make of disk, and doesn't appear when copying from the other. However, when I copy files from the current make of TDK DVD-R disks, all files are copied without any problems. The makes of DVD are both TDK DVD-R: an older style make with darker blue labels on the disks, and the current make of TDK DVD-R which has light blue labels.Įvery time I copy files from the older style DVDs, I get the "Data Error: Cyclic Redundancy Check" notice which stops me from copying any more files from the disc. I have been copying files (copy and paste) from 2 different makes of DVD onto my computer's main hard drive. I know there can be many variations of the problem depending on where the data is being copied from and to, but I seem to have have found where the source of my problem is. This topic has probably been brought up many times before, but has there ever been a fix for the common copying error, "Data Error: Cyclic Redundancy Check"?