Custom Query (1414 matches)

Hi,

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
root@rescue:~# 

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
Hence:
   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.

Seagate Barracuda 7200.14 (AF) ST1000DM003-1CH162 CC47

There is no firmware upgrade available for this model - only for ST1000DM003-9YN162.

Device: /dev/sdb [SAT], ST3500418AS, S/N:CENSORED, WWN:CENSORED, FW:HP34, 500 GB Device: /dev/sdb [SAT], found in smartd database 7.3/5610: Seagate Barracuda 7200.12 Device: /dev/sdb [SAT], WARNING: A firmware update for this drive may be available, see the following Seagate web pages: ​http://knowledge.seagate.com/articles/en_US/FAQ/207931en ​http://knowledge.seagate.com/articles/en_US/FAQ/213891en

The HP34 is customized HP firmware which cannot be officially reflashed with the Seagate FW update tool and is explicitly rejected by the tool. It seems HP doesn't have firmware update for linux machines using this drive, they have only HP40 version for Windows machines which seems to only resolves problem with the response time of the cold drive, i.e. nothing SMART related.

Nevertheless, the above warning is misleading and can even result that some brave people would brick their drives if they try to force flash the Seagate firmware because mixing the Seagate chip firmware with incompatible modules on the service area of the drive can lead to catastrophical results - invalid SMART attributes reported by the crippled firmware is one of the better results from the force flash.

drivedb.h 7.3/5610