Opened 4 years ago

Closed 3 years ago

#1303 closed defect (fixed)

Physical block size not displayed after a drive reset

Reported by: yhemery Owned by: Christian Franke
Priority: minor Milestone: Release 7.3
Component: smartctl Version: 7.1
Keywords: scsi Cc:



On the HGST SS300 (SAS SSD), smartctl won't display the drive physical block size if the drive just went through a soft reset (tested on r5031) :

root@rescue:~# smartctl -i /dev/sg22 | grep -i block
Logical block size:   512 bytes
Physical block size:  4096 bytes
root@rescue:~# sg_reset -d /dev/sg22
root@rescue:~# smartctl -i /dev/sg22 | grep -i block
Logical block size:   512 bytes

If we try to read the capacity using another tool, a Unit Attention is raised on the first command issued after the reset :

root@rescue:~# sg_reset -d /dev/sg22
root@rescue:~# sg_readcap -l /dev/sg22
read capacity (16):  Fixed format, current;  Sense key: Unit Attention
 Additional sense: Bus device reset function occurred
READ CAPACITY (16) failed: Unit attention
root@rescue:~# sg_readcap -l /dev/sg22
Read Capacity results:
   Protection: prot_en=0, p_type=0, p_i_exponent=0
   Logical block provisioning: lbpme=1, lbprz=1
   Last logical block address=781422767 (0x2e9390af), Number of logical blocks=781422768
   Logical block length=512 bytes
   Logical blocks per physical block exponent=3 [so physical block length=4096 bytes]
   Lowest aligned logical block address=0
   Device size: 400088457216 bytes, 381554.1 MiB, 400.09 GB

I enclosed the output of "smartctl -r scsiioctl -i /dev/sg22", and it looks like smartctl will fallback to a READ CAPACITY(10) when the first READ CAPACITY(16) failed :

>>>> do_scsi_cmnd_io: sg_io_ver=3
 [read capacity(16): 9e 10 00 00 00 00 00 00 00 00 00 00 00 20 00 00 ]
  scsi_status=0x2, sg_transport_status=0x0, sg_driver_status=0x8
  sg_info=0x1  sg_duration=4 milliseconds  resid=32
  status=2: sense_key=6 asc=29 ascq=3
scsiGetSize: READ CAPACITY(16) failed, res=8
>>>> do_scsi_cmnd_io: sg_io_ver=3
 [read capacity(10): 25 00 00 00 00 00 00 00 00 00 ]
  scsi_status=0x0, sg_transport_status=0x0, sg_driver_status=0x0
  sg_info=0x0  sg_duration=0 milliseconds  resid=0

This could probably be fixed by retrying the READ CAPACITY(16) when a Unit Attention is raised, but I don't know if this specific case is easy to detect ?

Feel free to ask if you need more details.

Attachments (1)

smartctl_scsiioctl_ssize.txt (3.1 KB ) - added by yhemery 4 years ago.
smartctl -r scsiioctl -i /dev/sg22

Download all attachments as: .zip

Change History (6)

by yhemery, 4 years ago

smartctl -r scsiioctl -i /dev/sg22

comment:1 by Christian Franke, 4 years ago

Milestone: unscheduled

Thanks for the detailed report.

comment:2 by yhemery, 3 years ago


For your information, a pull request was made for this ticket on the smartmontools Github:

comment:3 by Christian Franke, 3 years ago

Milestone: unscheduledRelease 7.3
Owner: set to Christian Franke
Status: newaccepted

comment:4 by Christian Franke, 3 years ago

Latest GH pull/114 applied with minor reformatting of ChangeLog entry. Thanks!

comment:5 by Christian Franke, 3 years ago

Resolution: fixed
Status: acceptedclosed
Note: See TracTickets for help on using tickets.