CODEWITHSUNDEEP
clinuxhard-drivesata
user2882307
user2882307

Reputation:

How can I identify the protocol used in hard disk?

I have an application which needs to read information from a hard disk, stuff like serial model etc.

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

Is there a reliable way that I can identify which protocol a connected drive uses? Either via an OS command or checking some logs or inquiring the device?

I don't want to use sysfs structure. I want to know how the OS know if it's an ATA, SCSI or whatever type of disk.

Upvotes: 7

Views: 6339

Answers (4)

Big Sam
Big Sam

Reputation: 1408

I like to simply run:

smartctl --scan

this should list all connected devices, along with the protocol for each device (ATA or SCSI)

Upvotes: 0

Am_I_Helpful
Am_I_Helpful

Reputation: 19168

As you have mentioned in comments to user3588161's answer, you are having SATA and SAS disk attached to the same SAS controller, so I'd suggest to use the smartctl command!

The smartctl command act as a control and monitor Utility for SMART disks under Linux and Unix like operating systems. Type the following command to get information about /dev/sda (SATA disk):

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

For SAS disk use one of the following syntax:

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

I guess all of the information is somehow related to this location :-

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

I suggest you try doing this too to check what output does it render.

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

(The backslashes next to zeros are for escaping special char :.)

Also, I'd like to suggest you to visit these two links in order for more information or detail like sample output,etc :-

Find Out Hard Disk Specs

To Check Disk behind Adaptec RAID Controllers

Upvotes: 6

Computer says 'no'--SOooooo
Computer says 'no'--SOooooo

Reputation: 5203

Answer rewritten in view of clarification: libATA is what you want. It's what hdparm calls and it reports the transport too. It's hard to find up to date docs on it though. See http://docs.huihoo.com/linux/kernel/2.6.26/libata/index.html for example.

I have not used libATA (directly) myself, so I can't be more specific as to the API calls needed. Since not many people need to write something like hdparm themselves, your best bet is to consult its sources to see what exactly it calls.

hdparm can report stuff 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 works on your system for SCSI drives (can happen) then it seems the problem is reduced to figuring out which of hdparm or sdparm to call isn't it? You could use udevinfo for that. See https://chromium.googlesource.com/chromiumos/third_party/laptop-mode-tools/+/775acea9e819bdee90cca8d2363827c13967a14b/laptop-mode-tools_1.52/usr/share/laptop-mode-tools/modules/hdparm for example.

Upvotes: 3

David C. Rankin
David C. Rankin

Reputation: 84609

Checking boot information, it seems the disk type is set in kernel ahci calls. You can check (as root) with dmesg | grep ahci (on sysvinit systems) or with journalctl -k -b -0 -l --no-pager | grep ahci (with systemd). The relevant query/setting looks to be:

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 holds the controller/type information you are looking for. This seems to be where the information comes from, but from your questions standpoint, it isn't a viable solution.

The question becomes where does this information get recorded or stored within /dev /proc or /sys. I have looked and cannot find a one-to-one correlation between this initial determination of disk type on boot and any flag stored. This information may well be part of the coded data, for example, /sys/class/scsi_disk/0:0:0:0/device or similar location. Hopefully this information may allow you or others to help pinpoint if, and if so, where this information is captured and available on a running system.

Upvotes: 3

Related Questions