Bug #4312
open
Dumps to USB storage report success but appear to not actually be written
0%
Description
As the subject says.
On latest Illumos, I was attempting to dump to a non-mpt_sas device to debug an mpt_sas-related panic/deadlock, which was causing dumping to the mpt_sas root drive to, well, deadlock.
Attached two known-working USB flash drives and one known working SATA HDD via a USB -> SATA bridge, created whole-disk pools, zfs create -V, dumpadm -d /dev/zvol/dsk/foo/bar, the devices added successfully, halt -d to test it, dump reports success, then on restart, savecore reports "bad magic number 0".
Eventually, I ended up wiring up the SATA HDD to the onboard internal SATA port, and it worked perfectly fine...but the failure to use 3 distinct USB storage devices makes me think something is wrong here.
I don't even know that it's unexpected that it doesn't work - but I think it's unexpected that it thinks it succeeds and then there is no data actually written.
Updated by Garrett D'Amore about 10 years ago
I'm pretty sure that the USB mass storage driver cannot operate in "polled" mode, which means it can't support system dumps. In fact, you'll see this in scsa2usb.c:
/*
* if we are in panic, we are in polled mode, so we can just
* accept the request, drop it and return
* if we fail this request, the rest of the file systems do not
* get synced
*/
if (ddi_in_panic()) {
extern int do_polled_io;
ASSERT(do_polled_io);
scsa2usb_prepare_pkt(scsa2usbp, pkt);
SCSA2USB_PRINT_SYNC_MSG(scsa2usb_sync_message, scsa2usbp);
mutex_exit(&scsa2usbp->scsa2usb_mutex);
return (TRAN_ACCEPT);
}
/* we cannot do polling, this should not happen */
if (pkt->pkt_flags & FLAG_NOINTR) {
USB_DPRINTF_L2(DPRINT_MASK_SCSA, scsa2usbp->scsa2usb_log_handle,
"NOINTR packet: opcode = 0%x", pkt->pkt_cdbp[0]);
mutex_exit(&scsa2usbp->scsa2usb_mutex);
return (TRAN_BADPKT);
}
"Fixing" this would be a very very difficult task indeed, because it would require changes to scsa2usb to support polled mode, and probably this means changes to USBA and the various host drivers.
Upshot of this is, dump to USB is not supported. And not likely to be supported anytime in the immediate future.
Updated by Garrett D'Amore about 10 years ago
- Category set to driver - device drivers
- Priority changed from Normal to Low
- Difficulty changed from Medium to Expert
Marking this "hard" and "low" priority, since its unlikely that anyone actually needs dump to USB, and the difficulty of supporting it means its unlikely to get any attention any time soon.
Updated by Garrett D'Amore over 9 years ago
What would be cool is to add some property that prevented attempts to set the dump device to something "non-useful". Only devices with a functional dump() should support it. Its a bit non-trivial because the abstraction of SCSI from USB makes it harder for the dump utility to know that it is speaking to a non-dump capable HBA.
Sees like this ought to be exposed as a scsi_ifgetcap() sort of thing.