Raspberry Pi OS • Re: Powered USB HDDs go offline during badblocks burn-in

I've plugged the two drives into a different Raspberry Pi 4b... more RAM (8GB vs 4GB), faster CPU (1.8GHz vs 1.5GHz). I also ran badblocks against a limited range of bytes and with selective patterns to confirm whether the drives were really failing. The following sample runs completed successfully without errors, and a spot check using a live hex editor confirmed it:

Code:

badblocks -b 8192 -c 1 -wsv -o badblocks.out -t 170 /dev/sdb 976753323 976753320badblocks -b 4096 -c 1 -wsv -o badblocks.out -t 85 /dev/sdb 1953506646 1953506640badblocks -b 4096 -c 1 -wsv -o badblocks.out -t 255 /dev/sdb 1953506646 1953506640badblocks -b 4096 -c 1 -wsv -o badblocks.out -t 0 /dev/sdb 1953506646 1953506640

Those runs completed successfully without error, so I ran a longer range which should've taken about 12 hours:

Code:

badblocks -b 65535 -c 512 -wsv -o badblocks.out -t 0 /dev/sda 122004096 122000000badblocks -b 65535 -c 512 -wsv -o badblocks.out -t 0 /dev/sdb 122004096 122000000

But that's now approaching 20 hours. Still no errors reported by badblocks but dmesg is filled with:

Code:

[Thu Apr 18 20:51:57 2024] sd 0:0:0:0: [sda] tag#1 uas_eh_abort_handler 0 uas-tag 11 inflight: IN [Thu Apr 18 20:51:57 2024] sd 0:0:0:0: [sda] tag#1 CDB: opcode=0x88 88 00 00 00 00 03 a0 44 bf 58 00 00 04 00 00 00[Thu Apr 18 20:51:57 2024] scsi host0: uas_eh_device_reset_handler start[Thu Apr 18 20:51:57 2024] usb 2-1: reset SuperSpeed USB device number 2 using xhci_hcd[Thu Apr 18 20:51:57 2024] scsi host0: uas_eh_device_reset_handler success[Thu Apr 18 21:27:35 2024] sd 1:0:0:0: [sdb] tag#0 uas_eh_abort_handler 0 uas-tag 11 inflight: IN [Thu Apr 18 21:27:35 2024] sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x88 88 00 00 00 00 02 eb d1 37 88 00 00 04 00 00 00[Thu Apr 18 21:27:35 2024] scsi host1: uas_eh_device_reset_handler start[Thu Apr 18 21:27:35 2024] usb 2-2: reset SuperSpeed USB device number 3 using xhci_hcd[Thu Apr 18 21:27:35 2024] scsi host1: uas_eh_device_reset_handler success

iostat still shows read/write activity. This time I'm going to wait it out.

In case anyone is interested, I chose the block_size and count_of_blocks values based on the "optimal transfer size" shown in dmesg when the disks initialized.

Code:

[Tue Apr 16 17:42:53 2024] sd 0:0:0:0: [sda] Preferred minimum I/O size 4096 bytes[Tue Apr 16 17:42:53 2024] sd 0:0:0:0: [sda] Optimal transfer size [b]33553920 bytes[/b] not a multiple of preferred minimum block size (4096 bytes)

33,553,920 = 2^25 - 2^9 --> (((2^16)-1) x 2^9) --> 65,535 x 512

Statistics: Posted by ejolson — Fri Apr 19, 2024 4:12 am