Announcement

Collapse
No announcement yet.

Linux 5.19 To Help With Reporting A Connected Device's Physical Location

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Linux 5.19 To Help With Reporting A Connected Device's Physical Location

    Phoronix: Linux 5.19 To Help With Reporting A Device's Connected Physical Location

    Being added to the Linux kernel's driver core code is sysfs support for reporting a physical location of a device on the connected system/server. In particular for large systems and servers with many connected devices and where there may be multiple devices of the same type/model, this physical location reporting to user-space should make it easier to distinguish...

    https://www.phoronix.com/scan.php?pa...sical-Location

  • #2
    Great! I hope this helps me locating what hard drive is connected to what controller and what drive actually got the error found in dmesg. The way it works now is not very intuitive...

    http://www.dirtcellar.net

    Comment


    • #3
      Originally posted by waxhead View Post
      Great! I hope this helps me locating what hard drive is connected to what controller and what drive actually got the error found in dmesg. The way it works now is not very intuitive...
      That reminds me of a conversation I had with my Dad last week.

      Dad: Move it down a hair.
      Me: OK. *lowers my end down a hair*
      D: No. I said down.
      M: OK. *lowers it down more*
      D: I said down!
      M: It's already so down it's on the ground!
      D: Wait!? That's not down!
      M: ???? Well what direction is "down"?
      D: Towards you.
      M: You should have said that to begin with.

      Your hard drive failed.
      Which hard drive?
      The one over yonder.
      Goddammit.
      Last edited by skeevy420; 01 May 2022, 01:41 PM.

      Comment


      • #4
        Originally posted by waxhead View Post
        Great! I hope this helps me locating what hard drive is connected to what controller and what drive actually got the error found in dmesg. The way it works now is not very intuitive...
        This was why I added my drives to ZFS by-label and then labeled what drive bays that had what drives with a bit of tape. Then in "zpool status " tells me that "seagate_1" has a problem. It's really nice that it can tell you which drive has a problem but it identifies them in the way the drives were originally presented.

        Could also have done it by cable id/location and marked the bays with that too I guess.

        Comment


        • #5
          Originally posted by waxhead View Post
          Great! I hope this helps me locating what hard drive is connected to what controller and what drive actually got the error found in dmesg. The way it works now is not very intuitive...
          Isn't this information already available in /dev/disk/by-* ? In your case specifically /dev/disk/by-path shows the controller PCI id and its port.
          Or do you want for it to be displayed in a more human readable way?

          Comment


          • #6
            Originally posted by numacross View Post

            Isn't this information already available in /dev/disk/by-* ? In your case specifically /dev/disk/by-path shows the controller PCI id and its port.
            Or do you want for it to be displayed in a more human readable way?
            A real life (just now) scenario:

            dmesg shows me the following.....
            ata1.00 is having a problem.

            Ok... so let's ls -la /dev/disk/by-path/ | grep -i ata-1
            Code:
            lrwxrwxrwx 1 root root 9 Mar 5 13:07 pci-0000:00:1f.2-ata-1.0 -> ../../sdk
            lrwxrwxrwx 1 root root 10 Mar 5 13:07 pci-0000:00:1f.2-ata-1.0-part1 -> ../../sdk1
            lrwxrwxrwx 1 root root 9 Mar 5 13:07 pci-0000:05:00.0-ata-1.0 -> ../../sdq
            lrwxrwxrwx 1 root root 10 Mar 5 13:07 pci-0000:05:00.0-ata-1.0-part1 -> ../../sdq1
            lrwxrwxrwx 1 root root 9 Mar 5 13:07 pci-0000:06:00.0-ata-1.0 -> ../../sds
            lrwxrwxrwx 1 root root 10 Mar 5 13:07 pci-0000:06:00.0-ata-1.0-part1 -> ../../sds1
            lrwxrwxrwx 1 root root 9 Mar 5 13:07 pci-0000:07:00.0-ata-1.0 -> ../../sdu
            lrwxrwxrwx 1 root root 10 Mar 5 13:07 pci-0000:07:00.0-ata-1.0-part1 -> ../../sdu1
            lrwxrwxrwx 1 root root 9 Mar 5 13:07 pci-0000:09:01.0-ata-1.0 -> ../../sda
            lrwxrwxrwx 1 root root 10 Mar 5 13:07 pci-0000:09:01.0-ata-1.0-part1 -> ../../sda1
            lrwxrwxrwx 1 root root 10 Mar 5 13:07 pci-0000:09:01.0-ata-1.0-part2 -> ../../sda2
            lrwxrwxrwx 1 root root 9 Mar 5 13:07 pci-0000:09:02.0-ata-1.0 -> ../../sde
            lrwxrwxrwx 1 root root 10 Mar 5 13:07 pci-0000:09:02.0-ata-1.0-part1 -> ../../sde1
            lrwxrwxrwx 1 root root 10 Mar 5 13:07 pci-0000:09:02.0-ata-1.0-part2 -> ../../sde2
            And by lsscsi | grep -i ata
            Code:
            00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 6 port SATA AHCI Controller (rev 06)
            05:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 01)
            06:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 01)
            07:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 01)
            08:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 01)
            09:01.0 Mass storage controller: Promise Technology, Inc. PDC20318 (SATA150 TX4) (rev 02)
            So in a setup like this.... how? ... how on earth.... well, maybe how is not the biggest question , but WHY is perhaps the better word...

            (For more decent controllers you get stuff like "...sas-phy0-lun0..." listed in by-path/ but still.... that is not the point)

            The above is from a fileserver box with 23 drives split one large, and two smaller filesystems. All BTRFS in redundant setup , however you can imagine the "fun" if BTRFS did not identify drives by ID and you are low on sleep when trying to debug this nugget of entertainment
            Last edited by waxhead; 02 May 2022, 01:41 PM. Reason: (included a little bit more info...)

            http://www.dirtcellar.net

            Comment


            • #7
              Originally posted by waxhead View Post
              The above is from a fileserver box with 23 drives split one large, and two smaller filesystems. All BTRFS in redundant setup , however you can imagine the "fun" if BTRFS did not identify drives by ID and you are low on sleep when trying to debug this nugget of entertainment
              I see, this is indeed a problem for systems with multiple (S)ATA controllers.

              Comment


              • #8
                I wonder if this would help with identifying USB controllers, along with what lanes/path a specific device/port is doing. Specifically, I'd like an easy way to determine whether a USB port is going through my CPU or chipset.

                Comment

                Working...
                X