Martin, > Hm, it sounds intriguing, but it has issues in its own right. For > years to come, user space will have to probe whether these attribute > exist, and fall back to the current ones ("wwid", "vpd_pg83") > otherwise. So user space can't be simplified any time soon. Speaking > for an important user space consumer of WWIDs (multipathd), I doubt > that this would improve matters for us. We'd be happy if the kernel > could just pick the "best" designator for us. But I understand that > the kernel can't guarantee a good choice (user space can't either). But user space can be adapted at runtime to pick one designator over the other (ha!). We could do that in the kernel too, of course, but I'm afraid what the resulting BLIST changes would end up looking like over time. I am also very concerned about changing what the kernel currently exports in a given variable like "wwid". A seemingly innocuous change to the reported value could lead to a system no longer booting after updating the kernel. (Ignoring for a moment that some arrays will helpfully add a new ID designator after a firmware upgrade and thus change what the kernel reports. *sigh*) > What is your idea how these new sysfs attributes should be named? Just > enumerate, or name them by type somehow? Up to you. Whatever you think would be easiest for userland to deal with. I don't have a good feeling for how common vendor specific ones are in practice. Things would obviously be easier if SCSI didn't have so many choices :( But taking a step back: Other than "it's not what userland currently does", what specifically is the problem with designator_prio()? We've picked the priority list once and for all. If we promise never to change it, what is the issue? -- Martin K. Petersen Oracle Linux Engineering -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel