How to disable detaching problematic USB disk

W

walder

Hello,

I've a friend's HDD I need to dd+fix; it's attached on a Sharkoon USB3 disk enclosure. As the disk has some bad blocks, the umass driver keeps detaching it after 5 retries, which is PITA as I need first to do a dd of it. It's a FreeBSD 10 box.

Disk is nicely attached:
Code: 
Aug 28 19:28:04 nasko ugen0.7: <JMicron> at usbus0
Aug 28 19:28:04 nasko umass3: <JMicron USB to ATAATAPI Bridge, class 0/0, rev 3.00/1.00, addr 6> on usbus0
Aug 28 19:28:04 nasko umass3:  SCSI over Bulk-Only; quirks = 0x8100
Aug 28 19:28:04 nasko umass3:11:3:-1: Attached to scbus11
Aug 28 19:28:04 nasko da11 at umass-sim3 bus 3 scbus11 target 0 lun 0
Aug 28 19:28:04 nasko da11: <WDC WD25 00AAJS-00L7A0 > Fixed Direct Access SCSI-2 device
Aug 28 19:28:04 nasko da11: Serial Number DA2453305FFF
Aug 28 19:28:04 nasko da11: 400.000MB/s transfers
Aug 28 19:28:04 nasko da11: 238475MB (488397168 512 byte sectors)
Aug 28 19:28:04 nasko da11: quirks=0x2<NO_6_BYTE>

I try to make an image file first:
dd if=/dev/da11 conv=sync,noerror bs=64K | gzip -c > /root/backup.img.gz

But the disk detaches after the first 5 errors are found:
Code: 
Aug 28 19:58:14 nasko (da11:umass-sim3:3:0:0): Error 5, Retries exhausted
Aug 28 19:58:14 nasko da11 at umass-sim3 bus 3 scbus11 target 0 lun 0
Aug 28 19:58:14 nasko da11: <WDC WD25 00AAJS-00L7A0 > s/n DA2453305FFF detached
Aug 28 19:58:14 nasko (da11:umass-sim3:3:0:0): Periph destroyed

I've read/tried all those "usbconfig", "umass quirks", "camcontrol", "sysctl" commands I could imagine are related to this problem but had no luck so far. The other question in this context: usbconfig was unable to list/find/cfg the once-detached da11 - is this by design? The device just disappears - I thought I could rescan/powerOn, but it's just vanished.

Any umass/disk guru here :-)? As a very last fallback I would attach it onto the MB SATA directly, but I would like to know if it's possible to do it via USB, as it would be much more usable!

Thank you,
Andrej
 
Why not go for SATA right away? If you're trying to safe data then I'd prioritize transfer speed: get the data secured as fast as possible. Of course it would depend on what SATA revision you're using, but in general its been my experience so far that SATA usually results in higher transfer speeds than USB mainly because of extra overhead here and there.
 
Have you tried the kern.cam.da.retry_count tunable? I think it would be best to set this as early as possible i.e. in /boot/loader.conf.
 
ShelLuser said:
Why not go for SATA right away? If you're trying to safe data then I'd prioritize transfer speed: get the data secured as fast as possible. Of course it would depend on what SATA revision you're using, but in general its been my experience so far that SATA usually results in higher transfer speeds than USB mainly because of extra overhead here and there.
Click to expand...

O prefer the stability of the system over speed - e.g. not to turn off the system, attach broken SATA drive, power up, attach ZFS pools.. I don't have hot-swap backplates nor hot-swap cables etc., just the pure mainboard cables coming out of the board - and I'm somehow afraid to 'hot-attach' the drive 'just-like-that' onto a running NAS installation.

Thank you,
Andrej
 
tobik said:
Have you tried the kern.cam.da.retry_count tunable? I think it would be best to set this as early as possible i.e. in /boot/loader.conf.
Click to expand...
Hm, I've just seen it but didn't test with that as I though it's what is says it is: "retry count" - but I need to disable the eject behavior after that counter reached, something like 'kern.cam.da.retries_reached_disable_ejecting' or something like that; but I didn't find anything like that so far ;-(.

Thank you,
Andrej
 
walder said:
I don't have hot-swap backplates nor hot-swap cables etc., just the pure mainboard cables coming out of the board - and I'm somehow afraid to 'hot-attach' the drive 'just-like-that' onto a running NAS installation.
Click to expand...
Those cables are exactly the same. Most modern mainboards have the option to turn "hot-swap" on or off in the BIOS/UEFI. Have a look for it.

But even long before these options existed I've been plugging in drives on running systems, those were old-school IDE drives. These were never intended to be hot-plugged but I never really had any problems with it besides the occasional crash of the OS. You just have to be careful to plug it in in one go (and the correct orientation). I don't recommend it though but it isn't as harmful as you think it is.
 
SirDice said:
Those cables are exactly the same. Most modern mainboards have the option to turn "hot-swap" on or off in the BIOS/UEFI. Have a look for it.

But even long before these options existed I've been plugging in drives on running systems, those were old-school IDE drives. These were never intended to be hot-plugged but I never really had any problems with it besides the occasional crash of the OS. You just have to be careful to plug it in in one go (and the correct orientation). I don't recommend it though but it isn't as harmful as you think it is.
Click to expand...

Problem with IDE cables and connectors was that the electronics connected directly to the IDE connectors didn't have any surge protection so if you were really unlucky (maybe because of some grounding issue) hot plugging could have ruined the electronics.
 
Thank you - but the problem is more low-level: the USB-cable attached disk is detached after a few (5?) errors.. So no app can help, when the low-level driver ejects the "bad" disk (yes, it's "bad", but this is the point, to attach it a read it into image!).

Thank you :)
 
It happens I have around a problematic 2.5" hd, WD 320, attached to an USB external enclosure, USB2.0 in my case, on a system running FreeBSD 10.3-p9

While I cannot dd-read the whole disk, because of errors, in my case the disk is not detached, and the error is slightly different:

Code: 
(da1:umass-sim1:1:0:0): READ(10). CDB: 28 00 00 69 e8 00 00 00 80 00
(da1:umass-sim1:1:0:0): CAM status: SCSI Status Error
(da1:umass-sim1:1:0:0): SCSI status: Check Condition
(da1:umass-sim1:1:0:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered read error)
(da1:umass-sim1:1:0:0): Error 5, Unretryable error
(da1:umass-sim1:1:0:0): READ(10). CDB: 28 00 00 69 e8 00 00 00 80 00
(da1:umass-sim1:1:0:0): CAM status: SCSI Status Error
(da1:umass-sim1:1:0:0): SCSI status: Check Condition
(da1:umass-sim1:1:0:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered read error)
(da1:umass-sim1:1:0:0): Error 5, Unretryable error

Don't know what to make of it, but may be it can help you, or may be attaching the disk to a sata port might be of help.

For reference, this is the device:
Code: 
ugen2.3: <JMicron> at usbus2
umass1: <MSC Bulk-Only Transfer> on usbus2
umass1:  SCSI over Bulk-Only; quirks = 0x4000
umass1:5:1:-1: Attached to scbus5
da1 at umass-sim1 bus 1 scbus5 target 0 lun 0
da1: <WDC WD32 00BEVT-75ZCT2 > Fixed Direct Access SCSI-2 device
da1: Serial Number xxxxxxxxxxxx
da1: 40.000MB/s transfers
da1: 305245MB (625142448 512 byte sectors)
da1: quirks=0x2<NO_6_BYTE>
 
You must log in or register to reply here.
Back
Top