How to determine the protocol used on the hard drive?

Question

I have an application that needs to read information from a hard drive, such as a serial model, etc.

Now, of course, it matters if the drive is a SAS, SATA or FC drive.

Is there a reliable way to determine which protocol a mapped drive uses? Or through an OS command or checking some logs or requesting a device?

I do not want to use the sysfs structure. I want to know how the OS knows whether it is ATA, SCSI or any type of disk.

Answer 1

As you mentioned in the comments on the user3588161 answer , you have a SATA and SAS drive attached to the same SAS controller, so I suggest using the smartctl command!

The smartctl team acts as a management and monitoring utility for SMART disks under Linux and Unix as operating systems. Type the following command to get information about / dev / sda (SATA drive):

 # smartctl -d ata -a -i /dev/sda 

For a SAS disk, use one of the following syntaxes:

 # smartctl -d scsi --all /dev/sgX # smartctl -d scsi --all /dev/sg1 # smartctl -d scsi --all /dev/sg1 -H 

I assume that all information is somehow related to this location: -

 /sys/class/scsi_device/?:?:?:?/device/model 

I suggest you try doing this to check what result it displays.

 cat /sys/class/scsi_device/0\:0\:0\:0/device/{model,vendor} 

(Backslashes next to zeros are designed to speed up special char : .)

In addition, I would like to invite you to visit these two links to get additional information or details, such as sample output, etc .: -

Find out the characteristics of your hard drive

Check drive behind Adaptec RAID controllers

Answer 2

The answer has been rewritten with clarifications: libATA is what you want. This is what causes hdparm , and it also reports this transport. However, it is difficult to find the latest documents on it. For example, http://docs.huihoo.com/linux/kernel/2.6.26/libata/index.html .

I myself have not used libata (directly), so I cannot be more specific regarding the required API calls. Since not many people need to write something like hdparm, it is best to consult its sources to find out exactly what it calls.

hdparm can report things like:

 [ root@alarmpi ~]# hdparm -I /dev/sdb /dev/sdb: ATA device, with non-removable media Model Number: TOSHIBA DT01ACA200 Serial Number: Z36GKMKGS Firmware Revision: MX4OABB0 Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0; Revision: ATA8-AST T13 Project D1697 Revision 0b 

If your actual problem is that only sdparm is running on your system for SCSI drives (it can happen), then it seems like the problem comes down to figuring out which hdparm or sdparm to call is it? You can use udevinfo for this. For example, https://chromium.googlesource.com/chromiumos/third_party/laptop-mode-tools/+/775acea9e819bdee90cca8d2363827c13967a14b/laptop-mode-tools_1.52/usr/share/laptop-mode-toolsarm

Answer 3

Checking boot information, it seems the disk type is set in kernel ahci calls. You can check (as root) with dmesg | grep ahci dmesg | grep ahci (on sysvinit systems) or using journalctl -k -b -0 -l --no-pager | grep ahci journalctl -k -b -0 -l --no-pager | grep ahci (using systemd). The corresponding request / parameter is as follows:

 kernel: ahci 0000:00:12.0: version 3.0 kernel: ahci 0000:00:12.0: controller can't do 64bit DMA, forcing 32bit kernel: ahci 0000:00:12.0: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode kernel: ahci 0000:00:12.0: flags: ncq sntf ilck pm led clo pmp pio slum part ccc 

The third line contains the controller / type information you are looking for. This seems to be where the information comes from, but, from the point of view of your questions, this is not a viable solution.

The question becomes where this information is written or stored in / dev / proc or / sys. I looked and can not find a one-to-one correlation between this initial definition of the type of disk at boot and the saved flag. This information may be part of encoded data, for example, /sys/class/scsi_disk/0:0:0:0/device or a similar location. We hope this information can allow you or others to help determine if and if so where this information will be captured and available in the running system.