Bug 2140728

Summary:	add device id type for dasd
Product:	Red Hat Enterprise Linux 9	Reporter:	David Teigland <teigland>
Component:	lvm2	Assignee:	David Teigland <teigland>
lvm2 sub component:	Devices, Filtering and Stacking	QA Contact:	cluster-qe <cluster-qe>
Status:	ASSIGNED ---	Docs Contact:
Severity:	unspecified
Priority:	unspecified	CC:	agk, heinzm, jbrassow, msnitzer, pcahyna, prajnoha, zkabelac
Version:	9.1	Keywords:	Triaged
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description David Teigland 2022-11-07 18:53:38 UTC

Description of problem:

IBM dasd devices should have their own device id type DEV_ID_TYPE_DASD for devices with major number 94 and the device id a string read from /sys/block/dasda/device/uid

from https://bugzilla.redhat.com/show_bug.cgi?id=2136906#c4

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 David Teigland 2022-11-07 22:16:57 UTC

patch that needs to be verified on a system with dasd devices
https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=e149a81be491f440ba0cce2a1a076a35aa5219be

Comment 2 Pavel Cahyna 2022-11-08 10:52:24 UTC

I found this documentation about DASD attributes:

https://www.ibm.com/docs/en/linux-on-systems?topic=dasds-dasd-information

The relevant part is:

uid 	A device identifier of the form <vendor>.<serial>.<subsystem_id>.<unit_address>.<minidisk_identifier> where

<vendor>
    is the specification from the vendor attribute.
<serial>
    is the serial number of the storage system.
<subsystem_id>
    is the ID of the logical subsystem to which the DASD belongs on the storage system.
<unit_address>
    is the address that is used within the storage system to identify the DASD.
<minidisk_identifier>
    is an identifier that the z/VM® system assigns to distinguish between minidisks on the DASD. This part of the uid is only present for Linux on z/VM and if the z/VM version and service level support this identifier.

This attribute is read-only.

Comment 3 David Teigland 2022-11-08 14:59:14 UTC

Thanks, AFAICS lvm won't need to parse the string components but just copy the entire thing as the device id.  Are you able to test the patch in comment 1?

Comment 4 David Teigland 2023-02-20 15:23:02 UTC

Hi Pavel, will you be able to test the patch in comment 1?

Comment 5 Pavel Cahyna 2023-03-13 11:53:03 UTC

(In reply to David Teigland from comment #4)
> Hi Pavel, will you be able to test the patch in comment 1?

Hi David,

I could test the patch, but I am not convinced anymore that adding this feature is right, because I am not sure how stable this identifier really is in practice (I am not familiar in detail with S/390). Sure, in normal operation the ID will remain the same, but what if the administrator decides to copy the VM data to another storage system (one of the components of the ID is "the serial number of the storage system"). Won't they expect that the VMs will work as before? This expectation would be broken by the proposed change.

I am afraid that the change thus has a potential to generate more support cases / bug reports. Is there a drawback with the current situation having block devices that do not have IDs known to LVM? Performance impact when LVM has to scan all the devices for metadata instead of only the right ones?

(I admit I am biased, because the devices file in general seems like a misfeature to me, the concerns above can apply also for other disk types.)

Comment 6 David Teigland 2023-03-13 15:33:10 UTC

We want the device id to act like a traditional WWID, and identify only the storage, not the host in any way.  i.e. the device id shouldn't change if the storage is moved to another system.  If the dasd id you described in comment 2 contains any host-specific field, then we could remove that component when generating the lvm device id.

Comment 7 David Teigland 2023-03-13 15:41:28 UTC

(In reply to Pavel Cahyna from comment #5)
> Is there a drawback with the current situation having
> block devices that do not have IDs known to LVM? Performance impact when LVM
> has to scan all the devices for metadata instead of only the right ones?

Yes, that's one issue.  In addition the lvm device id resolves problems when lvm PVs are cloned/copied and lvm doesn't know which one is correct, or problems where multipath component devices can be mistaken for the multipath device itself.

Comment 8 David Teigland 2023-03-13 15:51:15 UTC

(In reply to David Teigland from comment #7)
> In addition the lvm device id resolves problems when
> lvm PVs are cloned/copied and lvm doesn't know which one is correct, or
> problems where multipath component devices can be mistaken for the multipath
> device itself.

Sorry, those are just advantages compared to no device id at all.  The only real issue with using devname device id is more device scanning when device names change.