data error cyclic redundancy check when i try to initialize disk

[Dogsparky]

i literally just got this drive from UPS and not even 5 minutes ago put the drive into the computer, it is a WD blue, just tried to initialize it for the first time and now i am getting the "Data error (cyclic redundancy check)" error, i haven't used it at all prior, brand new drive just opened up disk management, gave me the pop up to initialize the disk and it just does that rendering it useless and i can't add volumes to it, or format it for use, how do i fix this or recover the drive? i don't need any data off this as there is none 

[WereCatf]

CRC-error means that there are bad sectors on the disk. If it's a brand new drive with bad sectors, I'd RMA it immediately. 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. There are multiple utilities for that, but e.g. booting Linux from a USB-stick and performing it there with hdparm is probably the easiest way. 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. (I often do this process to recover older disks)

[JacobFW]

try a different sata cable and a different sata port (don't use usb adapters for this).  

If it's works then great.  If not, return it.  A bad drive is a bad drive. Even data recovery pro's who fix drives do it just so they can get the data off and onto another drive, then they toss the original.

 

 

[JacobFW]

7 minutes ago, WereCatf said:

CRC-error means that there are bad sectors on the disk. If it's a brand new drive with bad sectors, I'd RMA it immediately. 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. There are multiple utilities for that, but e.g. booting Linux from a USB-stick and performing it there with hdparm is probably the easiest way. 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. (I often do this process to recover older disks)

Secure erase won't mark the sector as bad.  When a sector is added to the bad block list, the original block is not 0'd out.  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.  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.  Secure erase does nothing with the bad block list.  This is actually why Secure Erase is so much faster than simply formatting the drive.  The drive places the head at the very beginning of the platter, and then just starts writing 0's. 

 

EDIT:  Likely it's the Surface Test that's what actually marks the the blocks as bad. 

[Dogsparky]

6 minutes ago, JacobFW said:

try a different sata cable and a different sata port (don't use usb adapters for this).  

If it's works then great.  If not, return it.  A bad drive is a bad drive. Even data recovery pro's who fix drives do it just so they can get the data off and onto another drive, then they toss the original.

 

 

don't have any other sata cables and different ports didn't work, and WD is saying as this is the 4 drive i had to return because of defects, they will have to charge me 55 dollars just to get it replaced, at that point i can get just get a new drive from seagate or something 

[WereCatf]

Just now, JacobFW said:

Secure erase won't mark the sector as bad.  When a sector is added to the bad block list, the original block is not 0'd out.  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.  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.  Secure erase does nothing with the bad block list.  This is actually why Secure Erase is so much faster than simply formatting the drive.  The drive places the head at the very beginning of the platter, and then just starts writing 0's.  

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. 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.

[Dogsparky]

5 minutes ago, WereCatf said:

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. 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.

i don't have a USB stick to put linux on, is there a way to fix this without downloading anything? 

[WereCatf]

Just now, Dogsparky said:

i don't have a USB stick to put linux on, is there a way to fix this without downloading anything? 

There may be some Windows-based utilities, but I don't know of any personally. I never use Windows for anything important like e.g. data-recovery, secure erase or long-running selftests.

[JacobFW]

8 hours ago, Dogsparky said:

don't have any other sata cables and different ports didn't work, and WD is saying as this is the 4 drive i had to return because of defects, they will have to charge me 55 dollars just to get it replaced, at that point i can get just get a new drive from seagate or something 

ok, well before you go spend another 50 bucks or more on a new hard drive, buy 3 or 4 new sata cables.  If you've had multiple hard drives in a row with "defects", that might be a sign there's something else causing a problem here.  Don't get me wrong, the failure rate the manufacturers list is total b.s., but 4 failed hard drives in a row is highly unusual. 

 

How are they coming packaged? 

[JacobFW]

8 hours ago, WereCatf said:

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. 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.

Before I continue I just want to say one thing:  I'm not disagreeing with you to be a smartass or a know it all.  This genuinely conflicts with what I understand and am trying to understand if I'm misinformed.

 

Now, there's a bit of a conflict with what you said here.  Before you mentioned that you ran a secure erase, then a surface check test, then checked the SMART logs.  Now we're disagreeing with how secure erase affects the bad block list, so let's ignore that for a second.  As long as ECC is enabled, whenever the drive attempts to read a sector, it will check the data against the ECC, and if there's a conflict, attempt to read it again.  After a certain number of retries set by the manufacturer, the drive will mark the sector as bad, and any future data will be stored in the reallocated sector block. 

 

And as I mentioned before the standard reallocation procedure does not 0 out the sector if it's reallocated.  This is not an assumption on my part.  Data recovery and forensic investigators have shown that you can read the sector locations in the bad block list, clear the bad block list, then access the original sectors and can recover data (albeit usually corrupted).  This is part of the reason why I'm doubtful.  I simply don't give the hard drive manufacturers enough credit that they'll create a special version of the write routine with reallocation for the secure erase command (not to mention such a routine might not be in compliance with the secure erase standard which is required if they want to sell the drives to the government, one of their biggest buyers). 

And again, it doesn't make sense from a speed stand point.  For the reasons we both mentioned, the secure erase command is way faster than a format.  Reallocating a sector is very slow, as it must move the read head from it's current location, to the system area on the outside of the disc, then back to where it was to continue. 

 

Looking back at this post, I didn't mean to write that much, but I do think it explains my thoughts pretty well.  But getting back to the secure erase, my main question for you is, are you checking the smart logs immediately after the secure erase, before you attempt to access any data, or run any surface test, or are you doing something else first?

 

Again, not trying to be a smartass, genuinely curious.

 

 

[WereCatf]

2 minutes ago, JacobFW said:

Looking back at this post, I didn't mean to write that much, but I do think it explains my thoughts pretty well.  But getting back to the secure erase, my main question for you is, are you checking the smart logs immediately after the secure erase, before you attempt to access any data, or run any surface test, or are you doing something else first?

I used to check the actual number of reallocated sectors, but these days I just don't really have the interest. If there are CRC-errors on a drive, I chuck it in my server, run SMART surface-test (ie. smartctl -t long) to confirm that there are broken sectors, then run a secure erase, and then run another SMART surface-test to confirm whether the CRC-errors are gone or not. If the drive cannot even finish the secure erase or the CRC-errors persist, I toss it, but most of the drives I have lying around have been working fine for years after the erase. Since surface-test doesn't cause a reallocation, I don't see what else it would be that's causing it other than the secure erase.

[JacobFW]

1 minute ago, WereCatf said:

I used to check the actual number of reallocated sectors, but these days I just don't really have the interest. If there are CRC-errors on a drive, I chuck it in my server, run SMART surface-test (ie. smartctl -t long) to confirm that there are broken sectors, then run a secure erase, and then run another SMART surface-test to confirm whether the CRC-errors are gone or not. If the drive cannot even finish the secure erase or the CRC-errors persist, I toss it, but most of the drives I have lying around have been working fine for years after the erase. Since surface-test doesn't cause a reallocation, I don't see what else it would be that's causing it other than the secure erase.

Surface test does cause a reallocation.  That's it's point.  It's a proactive measure to find troublesome spots by writing garbage to them and seeing if they can retain it.  If they do great, it's probably still a good spot, but if not, the block is marked as bad, and you don't risk writing your own data to it.

 

But it's no different than any other read or write.  The standard procedure during a normal write operation, is to write a sector to a drive, then immediately read it back (i believe this can be disabled, but that's rare to do), and make sure both reading and writing worked correctly.  A surface test is no different.  You're giving the drive a chance to find the bad blocks before it threatens anything.  Generally the main difference is that a surface test might use bit patterns that are known to be harder for hard drives to read, so even if a sector might work for other bit patterns and go undetected, a surface test can prevent you from writing that one block that can't be recovered.

[WereCatf]

14 minutes ago, JacobFW said:

Surface test does cause a reallocation.

No, it very definitely doesn't. Go ahead and try it yourself. It's a read-only test and it aborts the test as soon as it hits a broken sector, reporting the LBA-address it aborted in the selftest-log. Take a look at the attached image: it's the output of the selftest-log and as you can see, the top-most selftest was aborted at 10% with a read-error.

[JacobFW]

1 minute ago, WereCatf said:

No, it very definitely doesn't. Go ahead and try it yourself. It's a read-only test and it aborts the test as soon as it hits a broken sector, reporting the LBA-address it aborted in the selftest-log.

That's interesting.  What program do you use to do the surface test? 

 

Reallocation can happen on reads as well.  It just sucks even harder:  if it happens on a write, well you have the original data still in the buffer that you can write to the reallocated block.  But if it get's reallocated during a read, then that data is considered lost.

 

If it really doesn't reallocate, then that is very weird.  It's not like an interrupt where you can intercept the reallocation procedure.  It happens independently of whatever program is sending commands to it.  As far as I know, the only ways it could do that would be to disable Error checking on the drive and have the program run it itself, or to clear the bad block list of that block after it gets reallocated.

 

Curiouser and curiouser.

 

 

[WereCatf]

1 minute ago, JacobFW said:

That's interesting.  What program do you use to do the surface test?

None, it's a SMART selftest, the drive's own controller performs the test completely independently of the rest system and doesn't require any program at all running on system-side.

[JacobFW]

2 minutes ago, WereCatf said:

None, it's a SMART selftest, the drive's own controller performs the test completely independently of the rest system and doesn't require any program at all running on system-side.

Ok, then what program do you use to enable the SMART selftest? hdparm?

[WereCatf]

Just now, JacobFW said:

Ok, then what program do you use to enable the SMART selftest? hdparm?

smartctl, from the smartmon-tools package.

[JacobFW]

3 minutes ago, WereCatf said:

smartctl, from the smartmon-tools package.

Neat, I'll take a closer look at it tomorrow.

And I'll concede this debate to you.

Thanks for tolerating me

[WereCatf]

Just now, JacobFW said:

Neat, I'll take a closer look at it tomorrow.

And I'll concede this debate to you.

Thanks for tolerating me

Absolutely no problem. I am pretty sure I am correct here, but if you can prove me wrong, I'd appreciate if you did pop in to let me know -- can't hurt to get corrected, other than one's fragile ego, eh?

[Dogsparky]

1 hour ago, JacobFW said:

ok, well before you go spend another 50 bucks or more on a new hard drive, buy 3 or 4 new sata cables.  If you've had multiple hard drives in a row with "defects", that might be a sign there's something else causing a problem here.  Don't get me wrong, the failure rate the manufacturers list is total b.s., but 4 failed hard drives in a row is highly unusual. 

 

How are they coming packaged? 

Ended up getting new data cables earlier,  still no luck, also tried different ports. 

 

And just packaged normally, no dings on them or anything