new 4TB SSD gives read errors

[bill_p]

OK, I have just copied the current Debian .iso onto the drive, using dd.

Code: Select all

# dd bs=4M if=debian-live-12.0.0-amd64-mate.iso  of=/dev/sda            
812+0 records in
812+0 records out
3405774848 bytes (3.4 GB, 3.2 GiB) copied, 806.674 s, 4.2 MB/s
#

Having completed that, I unplugged the drive, then pluuged it back in.

Here's the system log (dmesg | tail -40):

Code: Select all

[357537.080422] usb 1-3: new high-speed USB device number 27 using xhci_hcd
[357537.229558] usb 1-3: New USB device found, idVendor=048d, idProduct=1234, bcdDevice= 1.00
[357537.229567] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[357537.229570] usb 1-3: Product: USB 3.1
[357537.229572] usb 1-3: Manufacturer: PSSD
[357537.229575] usb 1-3: SerialNumber: 	
[357537.230929] usb-storage 1-3:1.0: USB Mass Storage device detected
[357537.231207] scsi host2: usb-storage 1-3:1.0
[357538.237029] scsi 2:0:0:0: Direct-Access     AL       SSD              5.00 PQ: 0 ANSI: 2
[357538.237357] sd 2:0:0:0: Attached scsi generic sg0 type 0
[357538.237723] sd 2:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
[357538.237924] sd 2:0:0:0: [sda] 1024000000 4096-byte logical blocks: (4.19 TB/3.81 TiB)
[357538.238086] sd 2:0:0:0: [sda] Write Protect is off
[357538.238089] sd 2:0:0:0: [sda] Mode Sense: 0b 00 00 08
[357538.238211] sd 2:0:0:0: [sda] No Caching mode page found
[357538.238213] sd 2:0:0:0: [sda] Assuming drive cache: write through
[357538.238995] sd 2:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
[357538.240238]  sda: sda1 sda2
[357538.240605] sd 2:0:0:0: [sda] Attached SCSI disk
[357538.247406] sd 2:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
[357538.247410] sd 2:0:0:0: [sda] tag#0 Sense Key : Illegal Request [current] 
[357538.247412] sd 2:0:0:0: [sda] tag#0 Add. Sense: Logical block address out of range                              <--------
[357538.247414] sd 2:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 3d 08 ff f0 00 00 01 00
[357538.247415] critical target error, dev sda, sector 8191999872 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
[357538.247935] sd 2:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
[357538.247938] sd 2:0:0:0: [sda] tag#0 Sense Key : Illegal Request [current] 
[357538.247940] sd 2:0:0:0: [sda] tag#0 Add. Sense: Logical block address out of range
[357538.247941] sd 2:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 3d 08 ff f0 00 00 01 00
[357538.247942] critical target error, dev sda, sector 8191999872 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[357538.247946] Buffer I/O error on dev sda, logical block 1023999984, async page read
#

The marked line suggest to me that this is not a real I/O error, but a value that has gone beyond an expected limit.

I don't use Windows, I persuaded a friend to let me use his system to check it out. ANd subsequently to try re-partioning it.

[CwF]

It looks like a capacity limit. Being unfamiliar with using large storage with usb I can only guess, out of my butt...

More familiar with the progression of drive capacities and bios/firmware/driver limits I lean now towards a bug of this nature. If it does work under windows that suggest the adapter is compliant. This leaves the Debian/Linux usb stack as suspect, which could lead to your particular usb hardware driver. So, if anyone could chime in on whether they have working usb storage >2-3GB then we want to know!

in the times before, we could short stroke or otherwise limit reported device size to overcome these types of limits. Without a limit lie, typically a partition within the bug limit should work without error. You may have tried this and I missed it, but try to partition a 1-2GB partition and leave the rest open to see if that is mountable and passes. If any process barfs on the reported true size and prevents a continue then I have no solution. The modern limit lie (think 90's LBA) would need a firmware mod, not desirable.

[Sommariva]

I have the same problem with this drive on a raspberry Pi 4 running either "Debian GNU/Linux 11 (bullseye)"or "Raspbian GNU/Linux 12 (bookworm)"

The drive works ok on both a Windows and Mac systems using either exFat and NTFS as the file systems, I also copied 2TB+ of data and all is good.

On the raspberry Pi 4 it also works using a exFat file system, also copied 2TB+ of data to this file system without any errors or performance issues.

Then on the raspberry Pi 4 if you make a 1st partition of around 95GB or less and format an ext4 file system with mkfs.ext4, this works without any problems too.
But now if you add more partitions and make an ext4 file system using mkfs.ext4, the mkfs.ext4 command runs as expected, but when you check these new file systems
with fsck they are all corrupted with many errors.
One side effect of adding more file systems is the first one which was working ok gets corrupted and stops working. then if you check it with fsck many errors are found and can not be
fixed. so somehow making the new file systems writes over the first filesystem.

Also if you make a 1st partition of more than 95GB with a ext4 file system this also is corrupted when you check with fsck, none of the corrupted file systems are able to mount.

When booting or plugging in the usb drive I still get the following errors from dmesg even if I have a working file system including exFAT.

Code: Select all

[81963.221535] usb 1-1.4: new high-speed USB device number 5 using dwc_otg
[81963.352504] usb 1-1.4: New USB device found, idVendor=048d, idProduct=1234, bcdDevice= 1.00
[81963.352555] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[81963.352578] usb 1-1.4: Product: USB 3.1
[81963.352597] usb 1-1.4: Manufacturer: PSSD
[81963.352614] usb 1-1.4: SerialNumber: 	
[81963.353843] usb-storage 1-1.4:1.0: USB Mass Storage device detected
[81963.355604] scsi host1: usb-storage 1-1.4:1.0
[81964.412414] scsi 1:0:0:0: Direct-Access     AL       SSD              5.00 PQ: 0 ANSI: 2
[81964.413503] sd 1:0:0:0: Attached scsi generic sg1 type 0
[81964.414324] sd 1:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16).
[81964.414794] sd 1:0:0:0: [sdb] 1024000000 4096-byte logical blocks: (4.19 TB/3.81 TiB)
[81964.415336] sd 1:0:0:0: [sdb] Write Protect is off
[81964.415370] sd 1:0:0:0: [sdb] Mode Sense: 0b 00 00 08
[81964.415779] sd 1:0:0:0: [sdb] No Caching mode page found
[81964.415808] sd 1:0:0:0: [sdb] Assuming drive cache: write through
[81964.418364] sd 1:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16).
[81964.420557]  sdb:
[81964.420828] sd 1:0:0:0: [sdb] Attached SCSI disk
[81964.500337] sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s
[81964.500391] sd 1:0:0:0: [sdb] tag#0 Sense Key : 0x5 [current] 
[81964.500415] sd 1:0:0:0: [sdb] tag#0 ASC=0x21 ASCQ=0x0 
[81964.500443] sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 3d 08 ff f0 00 00 01 00

[81964.500462] critical target error, dev sdb, sector 8191999872 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2

[81964.501207] sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s
[81964.501238] sd 1:0:0:0: [sdb] tag#0 Sense Key : 0x5 [current] 
[81964.501261] sd 1:0:0:0: [sdb] tag#0 ASC=0x21 ASCQ=0x0 
[81964.501284] sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 3d 08 ff f0 00 00 01 00

[81964.501301] critical target error, dev sdb, sector 8191999872 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[81964.501329] Buffer I/O error on dev sdb, logical block 1023999984, async page read

pi@piserver3:~ $ 

One interesting fact is you cannot format this device on a Mac system and get a working file system with any of the supported Mac file system formats.
(you get an error writing the partition table)
But you can format on a Windows system and you get a working device with either NTFS or exFAT.

So could just use exFat on the raspberry Pi 4, but not keen, I'm still having the errors at Boot time.

[iamkroot]

@bill_p Any updates after ~6 months? I recently got a new HDD and in a similar boat (`smartctl` throwing an error.) Wanted to check if you ever managed to get it resolved, or if I need to return this one.