This essentially reverts commit c9bd3d2 ("fix #1123: modify NVME
device path for SMART support").
The man page for smartctl states
> Use the forms "/dev/nvme[0-9]" (broadcast namespace) or
> "/dev/nvme[0-9]n[1-9]" (specific namespace 1-9) for NVMe devices.
so it should be fine to pass the path with the specific namespace to
smartctl.
But that text was already present in the man page of version 6.5,
which is the version the commit c9bd3d2 talks about. It might be that
it was necessary to drop the specific namespace for the version
backported from Stretch to Jessie (the bug report mentions that that
version was used[0]), but it's not quite clear.
With current versions, passing in the path with the specific namespace
did work as expected[1], even on a device with multiple namespaces set
up tested locally. In PBS, the path queried via
udev::Device::from_syspath("/sys/block/{name}") is passed to smartctl
and that also included the specific namespace on the systems I tested
with a short script.
So pass the full path to make things a little bit simpler and to avoid
potential future issues like bug #2020[2].
[0]: https://bugzilla.proxmox.com/show_bug.cgi?id=1123#c3
[1]: https://forum.proxmox.com/threads/113962/post-493185
[2]: https://bugzilla.proxmox.com/show_bug.cgi?id=2020
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
This reverts commit c3442aa554.
Nowadays, relying on 'readlink /sys/block/nvmeXnY/device' won't always
lead to the correct device, as reported in the community forum[0],
where it results in '../../nvme-subsys0' and there's no matching entry
under '/dev/'.
Since Linux kernel 5.4, in particular commit 733e4b69d508 ("nvme:
Assign subsys instance from first ctrl"), the problematic situation
from bug #2020 shouldn't happen anymore.
Stated more clearly by the commit's author here[1]:
> Indeed, that commit will make the naming a bit more sane and will
> definitely prevent mistaken identity. It is still possible to
> observe controllers with instances that don't match their
> namespaces, but it is impossible to get a namespace instance that
> matches a non-owning controller.
The only other user of get_sysdir_info() doesn't use the 'device'
entry, so reverting that part is fine too.
[0] https://forum.proxmox.com/threads/113962/
[1] https://github.com/linux-nvme/nvme-cli/issues/510#issuecomment-552508647
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Tested-by: Stefan Hrdlicka <s.hrdlicka@proxmox.com>
This makes it consistent with the naming scheme in PBS/GUI.
Keep value for API stability reasons and remove it in the next major version.
Signed-off-by: Matthias Heiserer <m.heiserer@proxmox.com>
Reviewed-by: Dominik Csapak <d.csapak@proxmox.com>
Tested-by: Dominik Csapak <d.cspak@proxmox.com>
for some controllers/disks there the line is
Percentage used endurance indicator: x%
so extend the regex for that possibilty.
We even had a test-case for SAS but did not notice we could extract
that info from there...
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
copied from test 'sas' with rotational set to 0
this has then the type 'ssd', rpm: 0, and health: 'OK'
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Provides recent test data for disk_tests/ssd_smart/sde_smart. The
previous data was created using an older smartmontools version, which
did not yet support the drive and therefore had bogus attribute mapping.
Signed-off-by: Jan-Jonas Sämann <sprinterfreak@binary-kitchen.de>
when compiling the disk list add a property with a stable
/dev/disk/by-id/ path for a block device when available.
This is needed to create zpools with the stable by-id links
The /dev/disk/by-id/ directory can contain multiple links to the same device
(e.g. when it's used as a LVM PV, or one for the wwn/nvme-eui in addition
to the one with vendor and serial). We take the first one which matches
the bus where the disk is attached. For nvme disks we exclude the one
containing the nvme-eui.
The patch assumes that not all disks need to have such a link (e.g.
virtio-block devices as we pass them to guests).
Additionally the tests were adapted to run successfully.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
we can only do this here, since the ceph cluster is not aware of
osd encryption, only the local node is (via ceph-volume and lv tags)
this way, we are able to show an 'encrypted' flag in the disk gui at least
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
sdd1 and sdd2 were listed in the zfs output but were not included
in the partlist, so the zfs detection test was wrong
now it is correct and more in line with the real world
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
ceph-volume creates osds/journal/etc. on LVM instead of partitions,
so to detect them, we have to parse the lv_tags of the LVs and
match them with the underlying device
also add tests for this detection
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
`nvmeX` devices nodes are apparently allocated independently
from their namespace block devices `nvmeXnY` and therefore
they are not strictly related by name. For instance:
$ readlink /sys/block/nvme0n1/device
../../nvme1
$ readlink /sys/block/nvme1n1/device
../../nvme0
Here /dev/nvme0n1 is the first namespace of /dev/nvme1 while
/dev/nvme1n1 is the first namespace of /dev/nvme0.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
in get_disks, when called with a parameter 'cciss/cXdY', we replaced
the '/' with '!' so that we can properly poll the information
about it from /sys/block/
but we have to replace the '!' with '/' again in our result list,
because the caller does not know anything about it and fails, because
the original dev is not in the list
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
this patch adds information about bluestore/db/wal to the disklist,
and we set the journal count only when we have at least one journal on
the disk
also adapt the regression tests
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
in my initial patch series for the regression test, i failed to notice
the missing attributes for the sandisk ssds (which had not been parsed)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
