4
[gala@arch ~]$ sudo !!
sudo hdparm -i /dev/sda

/dev/sda:

 Model=KINGSTON SHFS37A120G, FwRev=603ABBF0, SerialNo=50026B725B0A1515
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=unknown, MaxMultSect=1, MultSect=1
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=234441648
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 AdvancedPM=yes: unknown setting WriteCache=enabled
 Drive conforms to: unknown:  ATA/ATAPI-2,3,4,5,6,7

 * signifies the current active mode

Where does hdparm read the Model field from? Somewhere from sysfs ? Where from?

Jeff Schaller
  • 66,199
  • 35
  • 114
  • 250
Gala
  • 341
  • 2
  • 13

2 Answers2

8
# strace hdparm -i /dev/sda
…
ioctl(3, HDIO_GET_IDENTITY, 0x7fffa930c320) = 0
brk(0)                                  = 0x1c42000
brk(0x1c63000)                          = 0x1c63000
write(1, "\n", 1
)                       = 1
write(1, " Model=…

So hdparm gets its information from the HDIO_GET_IDENTITY ioctl, not from sysfs. That doesn't mean that the information can't be accessed from sysfs, of course.

Next we can look up HDIO_GET_IDENTITY in the kernel source. LXR is convenient for that. The relevant hit shows a call to ata_get_identity. This function looks up the model in the device description at the offset ATA_ID_PROD in the device description.

Looking at where else ATA_ID_PROD is used, and with sysfs in mind, we find a hit in ide-sysfs.c, in a function called model_show. This function is referenced by the macro call just below DEVICE_ATTR_RO(model), so if the ata driver is exposing the IDE interface, there's a file called model in the device's sysfs directory that contains this information.

If the ata driver is exposing the SCSI interface, tracing the kernel source is a lot more complicated, because the code uses different ways of extracting the information from the hardware. But as it turns out there is also a model field in the device's sysfs directory.

As for where the device's sysfs directory is, there are several ways to access it. The sysfs.txt file in the kernel documentation documents this, not very well. The simplest way to access it is via /sys/block which contains an entry for each block device:

$ cat /sys/block/sda/device/model

There are a lot of symbolic links in /sys. The “physical” location of that directory depends on how the disk is connected to the system; for example it has the form /sys/devices/pci…/…/ata…/host…/target…/… for an ATA device with a SCSI interface that's connected to a PCI bus.

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
  • This shows the difference between a hacker and a developer. A hacker like me tries to make stuff that works and has no idea what he is doing. A developer like you, knows exactly what he is doing and where to find what. Immacule info man, thanks! – Gala May 08 '16 at 22:35
1

Found it after an hour of digging:

gala@arch /sys/bus/scsi/devices/2:0:0:0 % pwd
/sys/bus/scsi/devices/2:0:0:0
gala@arch /sys/bus/scsi/devices/2:0:0:0 % cat model
KINGSTON SHFS37A

So for the model:

/sys/bus/scsi/devices/<device>/model

And vendor:

/sys/bus/scsi/devices/<device>/vendor
Gala
  • 341
  • 2
  • 13