ghw icon indicating copy to clipboard operation
ghw copied to clipboard

can not show mountpoint for nvme disk

Open zhangzhiqiangcs opened this issue 4 years ago • 9 comments

when I use ghw in my project on a machine with nvme, it just can not show nvme disk mountpoint. I just run the sample code as

package main

import (
	"fmt"

	"github.com/jaypipes/ghw"
)

func main() {
	block, err := ghw.Block()
	if err != nil {
		fmt.Printf("Error getting block storage info: %v", err)
	}

	fmt.Printf("%v\n", block)

	for _, disk := range block.Disks {
		fmt.Printf(" %v\n", disk)
		for _, part := range disk.Partitions {
			fmt.Printf("  %v\n", part)
		}
	}
}

Output

block storage (3 disks, 12TB physical storage)
 nvme0n1 SSD (4TB) NVMe [@pci-0000:83:00.0-nvme-1 (node #0)] vendor=unknown model=P5920CH0384M00 serial=SH205002054 WWN=eui.000000000000000138b19e72c8000806
 sda HDD (447GB) SCSI [@pci-0000:05:00.0-scsi-0:2:0:0 (node #0)] vendor=AVAGO model=MR9361-8i serial=600605b00fa0be4027f9a6220325d7f3 WWN=0x600605b00fa0be4027f9a6220325d7f3
  sda1 (447GB) [ext4] mounted@/
 sdb HDD (8TB) SCSI [@pci-0000:05:00.0-scsi-0:2:1:0 (node #0)] vendor=AVAGO model=MR9361-8i serial=600605b00fa0be4027f9a6310400af84 WWN=0x600605b00fa0be4027f9a6310400af84
  sdb1 (8TB) [ext4] mounted@/mnt/data

lsblk output

NAME    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda       8:0    0 446.6G  0 disk
└─sda1    8:1    0 446.6G  0 part /
sdb       8:16   0   7.3T  0 disk
└─sdb1    8:17   0   7.3T  0 part /mnt/data
nvme0n1 259:0    0   3.5T  0 disk /data

os information

NAME="Ubuntu"
VERSION="18.04.5 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.5 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

Did I use the code correctly ?

zhangzhiqiangcs avatar Jun 09 '21 05:06 zhangzhiqiangcs

At glance, it seems you used the code correctly, but we have a bug in the block pkg if there is a filesystem directly on the block device, and not on a partition of it. IOW:

  1. disk with 1 giant partition, filesystem on the giant partition -> should work
  2. disk without partition, filesystem on the block device directly -> seems broken

ffromani avatar Jun 11 '21 08:06 ffromani

understand. thanks for your reply. maybe I can help to fix this.

zhangzhiqiangcs avatar Jun 14 '21 17:06 zhangzhiqiangcs

Sure, I need to work on a reproducer myself and then we can create a fix. Feel free to contribute fixes if you have time, I'd be happy to review.

ffromani avatar Jun 14 '21 17:06 ffromani

by the way, I fond ghw can not aware the ssd disk when the disk is in a raid. I don't know there is a way to fix this. or there is no regular method to discover the disk type behind raid.

zhangzhiqiangcs avatar Jun 15 '21 08:06 zhangzhiqiangcs

If the disk is attached to a true raid controller, then there is no easy way (there could be controller-specific ways), because the intent of the controller is to mask what's attached to it and present an abstract storage entity to the OS - hence to ghw

ffromani avatar Jun 15 '21 09:06 ffromani

My fork (created to solve exactly this issue) treats a disk without partitions as if it has one partition. See tag 0.8.0-1:

https://github.com/taigrr/ghw/tree/v0.8.0-1

taigrr avatar Dec 03 '21 08:12 taigrr

My fork (created to solve exactly this issue) treats a disk without partitions as if it has one partition. See tag 0.8.0-1:

https://github.com/taigrr/ghw/tree/v0.8.0-1

This is very similar to what I had in mind to fix this issue. Would you be interested in sending a PR with your fix?

ffromani avatar Dec 03 '21 09:12 ffromani

No problem

taigrr avatar Dec 03 '21 18:12 taigrr

See #293

taigrr avatar Dec 03 '21 18:12 taigrr