Udev label removes corresponding fdisk, sfdisk or lsvdev entry

I'm curious about the behavior where any udev labeled device causes that corresponding listing to disappear from fdisk, sfdisk, or in the case of RDAC, lsvdev.

I have seen this on both EMC clariion and Sun Storagetek/Engenio 6540 arrays.

We use RHEL5.1 and udev to create persistent labels for Oracle devices.

Example udev rule:

# cat /etc/udev/rules.d/55-oracle-naming.rules
# Configure persistent, user-defined Oracle Clusterware device file names
KERNEL=="sd*", BUS=="scsi", PROGRAM=="/sbin/scsi_id", RESULT=="3600a0b8000476694000004704974f509", NAME="ocr1", OWNER="root", GROUP="oinstall", MODE="0640"
KERNEL=="sd*", BUS=="scsi", PROGRAM=="/sbin/scsi_id", RESULT=="3600a0b80004793a2000004ae4974e92d", NAME="ocr2", OWNER="root", GROUP="oinstall", MODE="0640"
KERNEL=="sd*", BUS=="scsi", PROGRAM=="/sbin/scsi_id", RESULT=="3600a0b8000478034000003e04974f6f0", NAME="ocr3", OWNER="root", GROUP="oinstall", MODE="0640"
KERNEL=="sd*", BUS=="scsi", PROGRAM=="/sbin/scsi_id", RESULT=="3600a0b80004793da000004904974e9b1", NAME="vot1", OWNER="oracle", GROUP="oinstall", MODE="0640"
KERNEL=="sd*", BUS=="scsi", PROGRAM=="/sbin/scsi_id", RESULT=="3600a0b8000476694000004734974f778", NAME="vot2", OWNER="oracle", GROUP="oinstall", MODE="0640"
KERNEL=="sd*", BUS=="scsi", PROGRAM=="/sbin/scsi_id", RESULT=="3600a0b80004793a2000004b14974ea59", NAME="vot3", OWNER="oracle", GROUP="oinstall", MODE="0640"

I'm comfortable that we can always reference the /dev/ocr* or /dev/vot* devices, I'm just looking for how to explain this behavior. Is there some mechanism under the hood causing it? Is it so someone doesn't do things with those fdisk listed devices and inadvertently wipe out udev labeled ones?

Thx

I cannot give you a 100% certainty that this will not fail, but I'm 98% certain that the scsi_id is unique and will always return the correct result and will faithfully identify the disk, even if the disks are move or renumbered.

redhat.com | Red Hat Magazine - Configuring Devices with udev

You are correct. That's the method I use to verify that that block device is indeed still there, but just being referenced by the new label.

Interestingly, /proc/partitions will always show those six missing devices that udev labels, but reading from them via dd by that sd device name will fail.