inxi result for "sg" devices

[metbog]

Hey guys,

What about devices which connected via raid-card? Can we get more info? For linux we can use something like this: hdparm -I /dev/sg[0-9]* 2>/dev/null |grep -E 'Model Number|Serial Number|device size with M = 1000\*1000'

[smxi]

https://raw.githubusercontent.com/torvalds/linux/master/Documentation/admin-guide/devices.txt

Of interest:

Most distributions name these /dev/sga, /dev/sgb...; this sets an unnecessary limit of 26 SCSI devices in the system and is counter to standard Linux device-naming practice.

It's unclear how old this comment is/was, but it sounds like this can be EITHER /dev/sgb OR /dev/sg2

https://tldp.org/HOWTO/SCSI-2.4-HOWTO/dnames.html

of interest:

SCSI devices that don't fit into these three categories (e.g. scanners) also appear as sg devices.

In other words, it appears that the case you note, an attached device to a hardware raid card, is a subset of possible devices that /dev/sg would show.

Other things that are not clear are how this would appear in /proc/partitions, I suggest copying in a full cat /proc/partitions of a system with /dev/sg device. The key here is the 'g', which means 'generic', which I assume means anything that is not covered by something else can be tossed in as a /dev/sg device.

The raid/drive/partitions logic is complicated, and more information is needed to see what /dev/sg devices actually would look like in the data. inxi doesn't use hdparm so don't show output from that, it's not useful.

Also df -hT from a /dev/sg system is needed.

I won't touch this until I have full data, ideally a current master inxi --debug 22

so I can see what the system actually does with /dev/sg data.

I suggest doing some more research to find what types of devices can appear as /dev/sg

However, a lot would be shown by /proc/partitions I believe.

I believe I can say this is an issue which will not progress without research and several --debug 22 datasets from systems that show /dev/sg devices, ideally a variety.

[metbog]

just sent inxi-xxx.xxx.xxx-2020-10-29_104323-root-3.1.07.tar.gz

[smxi]

ok, thanks, will see what we have re sg block data.

[smxi]

I'm glad I got a full debugger dataset, as far as I can tell, there are no block devices listed by anything inxi uses that reference /dev/sg[0-9]. The only reference anywhere to such devices is in /dev itself, where there appears to be an autogenerated list of /dev/sg[0-9].

I assume this is the Adaptec hardware raid device that inxi lists under RAID:, and I further assume the attached drive is either /dev/sdb or /dev/sdc, which can't be mapped to /dev/sg anything as far as I can tell on first look.

inxi does a lot of disk tool logging for exactly this reason when the debugger runs, to check a long list of possible data sources for block device data, including tools that inxi might one day use, but doesn't currently use, but nothing shows /dev/sg anything.

Basically, it appears to me to be a chicken egg situation, you 'know' that the /dev/sg device is a block device, but inxi does not appear to have any way to actually determine this, nor is there any logical place to put such information, since it's not mappable to the apaptec hardware raid device, unless it is, but I don't know any way to do that, and the /dev/sda b c devices are already handled, so there's no logical place to use any information about /dev/sg there either.

Listing /dev/sg without further processing also seems to be a useless activiity since those appear to be autopopulated, or generated in some way that doesn't actually refer to a specific drive, unless you have 10 drives attached to the hardware raid?

Mostly we're left with hanging threads and questions, and no obvious or even non obvious way to do anything with /dev/sg data, and since the 'g' stands for generic, we can't assume it even is a block device in the first place, so this doesn't seem like it can really be useful data unless there's some way to link /dev/sg devices to /dev/sdx or hardware raid report that isn't totally convoluted.

hdparm seems to be the only actual tool that can understand this request, but it's using your user provided data to give you the list, that is, you decided and gave it the /dev/sg* request, it didn't volunteer it as a possible block device as far as I can tell, but I don't really use hdparm so I don't know it.

Just out of curiousity, what is the full output of:

hdparm -I /dev/sg*

Anyway, that's what I see on first look, nothing usable.

[smxi]

Note that while looking into another issue, I noticed that /proc/scsi/sg/device* actually has sg data, though I have no idea how to make it turn into something meaningful. It just seems to list all the block devices on the system, but it does have tables of types etc, but it's not easy data to make sense out of, and it probably doesn't get you any close to sg raid information. But just noting this here so I don't forget that possible source.

[abucodonosor]

Ehh...

That isn't going to work for various reasons. All distributions have sg enabled ( scsi_generic ) so all sata/scsi devices are an sg symlink.

Also, what do you mean by 'raid-card'?, bc that depends on how the devices are connected, which vendors, etc.

[smxi]

I assume the issue poster means just in a generic sense a device that is hardware raid, but since most users experience hardware raid via a raid controller card, that's the term he used. I used to call Devices in inxi 'Cards' too by the way, for the same reason, but had to stop because with laptops and builtin hardware features, more and more devices were not cards, unlike the old days of pcs, when almost everything was a card.

I wasn't posting the above as a solution, just a note to add to this thread since I'd never remember it otherwise, it's just something I noticed when looking through proc for another reason. I don't see anything happening with sg but you never know, I don't mind leaving issues open for years if they aren't invalid or pointless. Something might one day come out of it.