public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	Fiona Ebner <f.ebner@proxmox.com>
Subject: [pve-devel] applied: [RFC v2 storage] Revert "Fix #2020: use /sys to map nvmeXnY to nvmeX"
Date: Wed, 30 Nov 2022 16:35:18 +0100	[thread overview]
Message-ID: <16a833e0-c5ee-7d61-2ead-9c30df515184@proxmox.com> (raw)
In-Reply-To: <20221128112949.75356-1-f.ebner@proxmox.com>

Am 28/11/2022 um 12:29 schrieb Fiona Ebner:
> This reverts commit c3442aa5546b029a524928d10c7ecabe0024c137.
> 
> 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>
> ---
> 
> Changes from v1:
>     * Rebase on current master.
>     * Squash in style change putting post-if on the same line.
> 
> Alternatively, we might want to switch to passing the namespaced
> device name directly to smartctl. According to 'man smartcl', it's
> supported and it works for me and the user in the forum. However,
> AFAICT, the stated support was already present in smartmontools 6.5,
> but c9bd3d2 ("fix #1123: modify NVME device path for SMART support")
> references that version and mentions that it's necessary to drop the
> namespace, so really not sure.

might want to try that then, we hopefully have a NVMe device with namespace
support, if not we can always get one.

> 
>  PVE/Diskmanage.pm                                      | 10 +---------
>  test/disk_tests/nvme_smart/nvme0n1/device              |  1 -
>  .../nvme_smart/{nvme0 => nvme0n1/device}/model         |  0
>  3 files changed, 1 insertion(+), 10 deletions(-)
>  delete mode 120000 test/disk_tests/nvme_smart/nvme0n1/device
>  rename test/disk_tests/nvme_smart/{nvme0 => nvme0n1/device}/model (100%)
> 
>

applied for now as stop-gap, thanks!




      parent reply	other threads:[~2022-11-30 15:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-28 11:29 [pve-devel] " Fiona Ebner
2022-11-28 16:16 ` Stefan Hrdlicka
2022-11-30 15:35 ` Thomas Lamprecht [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=16a833e0-c5ee-7d61-2ead-9c30df515184@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=f.ebner@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal