Solved Signs of a dead drive

the3ajm

the3ajm

I am wiping a drive with the following command:

dd if=/dev/zero of=/dev/da0 status=progress

It gave me this message shortly after:

Code: 
dd: /dev/da0: Input/output error transferred 45.001s, 990 kB/s  

87445+0 records in
87444+0 records out
44771328 bytes transferred in 71.631520 secs (625023 bytes/sec)

Here's the dmesg log of the drive and behavior:

Code: 
ugen6.3: <vendor 0x05e3 USB Storage> at usbus6 (disconnected)
umass0: at uhub4, port 1, addr 3 (disconnected)
umass0: detached
ugen6.3: <vendor 0x05e3 USB Storage> at usbus6
umass0 on uhub4
umass0: <vendor 0x05e3 USB Storage, class 0/0, rev 2.00/0.14, addr 3> on usbus6
umass0:  SCSI over Bulk-Only; quirks = 0x408c
umass0:4:0: Attached to scbus4
da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
da0: <HITACHI_ DK23FA-80 0014> Fixed Direct Access SCSI device
da0: 40.000MB/s transfers
da0: 76319MB (156301488 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>
(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 01 55 94 00 00 01 00
(da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 01 55 94 00 00 01 00
(da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain
(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 01 55 94 00 00 01 00
(da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(da0:umass-sim0:0:0:0): Retrying command, 1 more tries remain
(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 01 55 94 00 00 01 00
(da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(da0:umass-sim0:0:0:0): Retrying command, 0 more tries remain
(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 01 55 94 00 00 01 00
(da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(da0:umass-sim0:0:0:0): Error 5, Retries exhausted
(da0:umass-sim0:0:0:0): got CAM status 0x44
(da0:umass-sim0:0:0:0): fatal error, failed to attach to device
da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
da0: <HITACHI_ DK23FA-80 0014>  detached
g_access(961): provider da0 has error 6 set
g_access(961): provider da0 has error 6 set
g_access(961): provider da0 has error 6 set
(da0:umass-sim0:0:0:0): Periph destroyed

I think this may be a sign of a dying drive so I'll continue to look for further confirmation before closing this thread.
 
The bit shifted addresses in bytes 2-5 are your problem, ie 01 55 94. These are the logical blocks on the disk(16856926). So, yes, it could be a failing drive. You could install smart utilities to check it and see if it is reporting errors or bad blocks un-mapped out.
May I suggest using a larger block size than 1 to see if the problem rectifies itself?
Also, it wouldn't hurt to disengage the USB drive to see if that resets it (un-plug it, plug it).
 
Erasing the drive the hard way:

Preparation: Unfortunately, FreeBSD doesn't have 'hdparm', so you must use some live linux distro to do it. It's best to use SATA connection for this, with USB it may fail miserably. Make sure you have plugged in only the drive you want to wipe out, any mistake can be disastrous, so bear this in mind, it's *dangerous*, and you're doing this on your own risk.
I assume your drive is /dev/sda, if not, change it accordingly
First run as root
# hdparm -I /dev/sda (that's a big I as in Internet). In the Master password section you should see something like this:
supported not frozen
and time for 'security erase' (or better 'enhanced erase' if your drive supports it).

If it says frozen you must unfreeze it first, to do that: # echo 1 > /sys/block/sda/device/delete and unplug your disk completely. Plug it again, now hdparm -I /dev/sda should say 'not frozen'.

Now set password for your disk:
hdparm --user-master u --security-set-pass p /dev/sda
Now in hdparm -I /dev/sda output you should see Master password enabled and security level high.

Erase your drive:
hdparm --user-master u --security-erase p /dev/sda (or hdparm --user-master u --security-erase-enhanced p /dev/sda if your drive supports it).
Wait until it ends, and do not turn off your computer!
To make sure it ended succesfully run # hdparm -I /dev/sda once again, it should state master password not enabled. If it's still enabled you must do --security-erase once again.
And that's it :)
 
mark_j said:
May I suggest using a larger block size than 1 to see if the problem rectifies itself?
Click to expand...

I did try that by appending bs=512K to the command.

mark_j said:
You could install smart utilities to check it and see if it is reporting errors or bad blocks un-mapped out.
Click to expand...

I'll try to see if there are tools that work, I did found out the drive did get wiped since it wasn't able to determine it's a ext2fs anymore so I'll perform a check if the drive is good first.
 
It couldn't determine the drive had a file system on it because your use of dd, before it crashed, wiped out the file, directory and partition structure.

You can normally do this by just wiping out the 1st MB or two of the disk in question. For example bs=1m count=2, but it wouldn't detect the error you encountered. This may be a good thing, though probably a disaster waiting to happen if you rely on the disk.

Only running dd again, with say a blocksize of 1MB (bs=1M) will perhaps encounter the error again. This helps to not torture the USB drive as much when the block size is larger or at the very least a sector size of the medium in question.

As grahamperrin said in message 3, use smart tools to give you more insight. (BTW, USB has nothing to do with SMART, it's just a medium for transfer. SMART is disk information collected by the disk's firmware).
 
How about a much simpler solution: Ask the drive to reformat. That will definitely get rid of the data stored on it, better than dd. And if the IO errors are caused by problems with the platters or heads, it might be able to fix some of those, by creating a new track layout with spare space.

You can do that with camcontrol, or you can install sg_utils and send the format command yourself.
 
mark_j said:
For example bs=1m count=2, but it wouldn't detect the error you encountered. This may be a good thing, though probably a disaster waiting to happen if you rely on the disk.
Click to expand...
That look to did the trick and didn't give out an error. I am now able to format the drive to ext2fs and checked that the device doesn't support SMART:

Code: 
smartctl 7.2 2021-09-14 r5236 [FreeBSD 12.2-RELEASE-p12 amd64] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               HITACHI_
Product:              DK23FA-80
Revision:             0014
User Capacity:        80,026,361,856 bytes [80.0 GB]
Logical block size:   512 bytes
scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
>> Terminate command early due to bad response to IEC mode page

=== START OF READ SMART DATA SECTION ===
Current Drive Temperature:     0 C
Drive Trip Temperature:        0 C

Error Counter logging not supported

scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
Device does not support Self Test logging

At the meantime I did try to put files in there and seems to be working, now I'll try to figure out how to perform transfer as a user.

Thanks for everyone's help.
 
Friend Of Jolly Devil said:
Erasing the drive the hard way:
Click to expand...
This post IMHO needs a few remarks...

First and foremost, the tool to access/control SCSI and ATA devices on FreeBSD is camcontrol(8). Of course you can use it for anything you'd use hdparm on Linux for.

Then, on the issue of securely erasing a drive in general:
  • For (classic) HDDs, dd is the way to go. You just might want to use /dev/random instead of /dev/zero to avoid the (pretty theoretical) problem of data that could be recovered from the edge of the track.
  • The reason this doesn't work for SSDs is their "intelligent" firmware implementing wear-balancing and also using spare flash cells for that: You can never be 100% sure you actually overwrote some cell.
  • The solution for SSDs is this "secure erase" command implemented by their firmware. Be aware you have to trust the (closed-source) firmware to do the right thing. This will be the case most of the time of course, but there were reports of implementations getting it wrong (leaving data in some cells). Again, no way to be sure. AFAIK, there are also firmwares out there that just don't implement secure erase.
  • My recommendation is: Think proactive. If you have an SSD and you consider you might have to "wipe" it some day (e.g. for selling it), use full disk encryption on it, ideally before ever writing the first byte. Then, just throwing away your key will be enough.
 
Zirias said:
First and foremost, the tool to access/control SCSI and ATA devices on FreeBSD is camcontrol(8). Of course you can use it for anything you'd use hdparm on Linux for.
Click to expand...
I have a problem with finding dco functionality in camcontrol, is it implemented? Camcontrol doesn't have too much documentation yet, I need to experiment with it to feel more comfortable to use it.
 
the3ajm said:
=== START OF INFORMATION SECTION ===
Vendor: HITACHI_
Product: DK23FA-80
Click to expand...

If this is correct this drive is an almost 20 year old dinosaur that belongs in a museum. Every minute spent testing this thing or even trying to keep it alive is just a waste of energy...
Even if the error messages disappear after all those efforts I wouldn't trust that drive even half the way I could throw it as it very likely will die in the near future anyways.

If you absolutely have to keep this ancient system running just slap in any cheap SSD. If the system doesn't have any SATA connectors, get a 44pin/sata-adapter or a PCI SATA-controller, they are also dirt-cheap.
 
I have an almost 18 year old Hitachi in an old Apple laptop. While it's not on very often these days, it still spins up without a problem.
Hitachi used to be a fabulous manufacturer. Their quality was top notch even in their consumer model disks. Now, if this was a Western Digital disk it would have died a long time ago.
There may be a reason the op cannot change the disk: not enough room in the computer to fit a IDE to SATA converter.
 
Seconding that mark_j, I don't throw HDDs away just because they're old. SMART gives you a pretty good idea about the actual state of your hardware. If it still looks good, why not keep using it...

(edit: that said, never rely on a single drive for your valuable data of course. Use for example raid-z1, raid-z2 etc ... and of course, have some off-site backups!)
 
You must log in or register to reply here.
Back
Top