ebsnvme-id triggers unnecessary kernel change events

[nmeyerhans]

Observed on the current master branch, as well as versions packaged in Debian and Amazon Linux 2.

By opening the nvme block devices in read/write mode, ebsnvme-id triggers a kernel "change" event, which translates to the device nodes corresponding to the partitions being deleted and recreated. Similarly, the sysfs files corresponding with the partitions are also deleted and recreated.

To reproduce:

1. Launch an EC2 instance with a partitioned secondary EBS volume attached (seen as /dev/nvme1n1 here):

    admin@ip-10-0-0-75:~$ lsblk 
    NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
    nvme0n1      259:0    0    8G  0 disk 
    ├─nvme0n1p1  259:1    0  7.9G  0 part /
    └─nvme0n1p15 259:2    0  127M  0 part /boot/efi
    nvme1n1      259:3    0    8G  0 disk 
    ├─nvme1n1p1  259:4    0  7.9G  0 part 
    ├─nvme1n1p14 259:5    0    3M  0 part 
    └─nvme1n1p15 259:6    0  124M  0 part 
   

2. Note the inode number of one of the partition device nodes in /dev, e.g:

    admin@ip-10-0-0-75:~$ stat --format="%i" /dev/nvme1n1p1
    566
   

3. Start udevadm monitor in a second session.

4. Run sudo /sbin/ebsnvme-id /dev/nvme1n1

5. Note the inode number of the partition device:

    admin@ip-10-0-0-75:~$ stat --format="%i" /dev/nvme1n1p1
    598
   

6. Note the output of udevadm monitor, which will indicate the child device removal and recreation similar to the following:

    KERNEL[5283.274948] remove   /devices/pci0000:00/0000:00:1f.0/nvme/nvme1/nvme1n1/nvme1n1p1 (block)
    KERNEL[5283.275107] remove   /devices/pci0000:00/0000:00:1f.0/nvme/nvme1/nvme1n1/nvme1n1p14 (block)
    KERNEL[5283.275215] remove   /devices/pci0000:00/0000:00:1f.0/nvme/nvme1/nvme1n1/nvme1n1p15 (block)
    KERNEL[5283.279198] change   /devices/pci0000:00/0000:00:1f.0/nvme/nvme1/nvme1n1 (block)
    KERNEL[5283.279340] add      /devices/pci0000:00/0000:00:1f.0/nvme/nvme1/nvme1n1/nvme1n1p1 (block)
    KERNEL[5283.279420] add      /devices/pci0000:00/0000:00:1f.0/nvme/nvme1/nvme1n1/nvme1n1p14 (block)
    KERNEL[5283.281014] add      /devices/pci0000:00/0000:00:1f.0/nvme/nvme1/nvme1n1/nvme1n1p15 (block)
    UDEV  [5283.339467] remove   /devices/pci0000:00/0000:00:1f.0/nvme/nvme1/nvme1n1/nvme1n1p15 (block)
    UDEV  [5283.345292] remove   /devices/pci0000:00/0000:00:1f.0/nvme/nvme1/nvme1n1/nvme1n1p14 (block)
    UDEV  [5283.356890] remove   /devices/pci0000:00/0000:00:1f.0/nvme/nvme1/nvme1n1/nvme1n1p1 (block)
    UDEV  [5283.410338] change   /devices/pci0000:00/0000:00:1f.0/nvme/nvme1/nvme1n1 (block)
    UDEV  [5283.526077] add      /devices/pci0000:00/0000:00:1f.0/nvme/nvme1/nvme1n1/nvme1n1p14 (block)
    UDEV  [5283.555895] add      /devices/pci0000:00/0000:00:1f.0/nvme/nvme1/nvme1n1/nvme1n1p1 (block)
    UDEV  [5283.570766] add      /devices/pci0000:00/0000:00:1f.0/nvme/nvme1/nvme1n1/nvme1n1p15 (block)
   

Similar behavior can be observed with respect to the files in the /sys/block/nvme1n1/nvme1n1p*/ directories.

Since the ebsnvme-id script is only supposed to be gathering metadata about volumes in a read-only manner, its invocation should not trigger a kernel change event.