On Thu, Nov 03, 2022 at 09:57:20AM -0500, Eric Sandeen wrote: > On 11/3/22 8:32 AM, Lukas Czerner wrote: > > On Tue, Nov 01, 2022 at 12:19:06PM -0500, Eric Sandeen wrote: > >> From: Lukas Herbolt <lukas@xxxxxxxxxxx> > >> > >> As of now only device names are printed out over __xfs_printk(). > >> The device names are not persistent across reboots which in case > >> of searching for origin of corruption brings another task to properly > >> identify the devices. This patch add XFS UUID upon every mount/umount > >> event which will make the identification much easier. > >> > >> Signed-off-by: Lukas Herbolt <lukas@xxxxxxxxxxx> > >> [sandeen: rebase onto current upstream kernel] > >> Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx> > > > > Hi, > > > > it is a simple enough, nonintrusive change so it may not really matter as > > much, but I was wondering if there is a way to map the device name to > > the fs UUID already and I think there may be. > > > > I know that udev daemon is constantly scanning devices then they are > > closed in order to be able to read the signatures. It should know > > exactly what is on the device and I know it is able to track the history > > of changes. What I am not sure about is whether it is already logged > > somewhere? > > > > If it's not already, maybe it can be done and then we can cross > > reference kernel log with udev log when tracking down problems to see > > exactly what is going on without needing to sprinkle UUIDs in kernel log ? > > > > Any thoughts? > > Hm, I'm not that familiar with udev or what it logs, so I can't really say > offhand. If you know for sure that this mapping is possible to achieve in > other ways, that may be useful. > > I guess I'm still of the opinion that having the device::uuid mapping clearly > stated at mount time in the kernel logs is useful, though; AFAIK there is no > real "cost" to this, and other subsystems already print UUIDs for various > reasons so it's not an unusual thing to do. > > (I'd have hesitated to add yet another printk for this purpose, but extending > an existing printk seems completely harmless...) > > -Eric I have no strong opinion either way, just trying to explore avenues we may already have. When I do mkfs.xfs -f /dev/vdb this is what I get from: udevadm monitor --environment monitor will print the received events for: UDEV - the event which udev sends out after rule processing KERNEL - the kernel uevent KERNEL[187.052212] change /devices/pci0000:00/0000:00:01.6/0000:07:00.0/virtio5/block/vdb (block) ACTION=change DEVPATH=/devices/pci0000:00/0000:00:01.6/0000:07:00.0/virtio5/block/vdb SUBSYSTEM=block SYNTH_UUID=0 DEVNAME=/dev/vdb DEVTYPE=disk DISKSEQ=2 SEQNUM=3494 MAJOR=252 MINOR=16 UDEV [187.069279] change /devices/pci0000:00/0000:00:01.6/0000:07:00.0/virtio5/block/vdb (block) ACTION=change DEVPATH=/devices/pci0000:00/0000:00:01.6/0000:07:00.0/virtio5/block/vdb SUBSYSTEM=block SYNTH_UUID=0 DEVNAME=/dev/vdb DEVTYPE=disk DISKSEQ=2 SEQNUM=3494 USEC_INITIALIZED=4425234 ID_PATH=pci-0000:07:00.0 ID_PATH_TAG=pci-0000_07_00_0 ID_FS_UUID=61c0b0c8-2f9e-4fbf-817d-eda65b0363d5 ID_FS_UUID_ENC=61c0b0c8-2f9e-4fbf-817d-eda65b0363d5 ID_FS_TYPE=xfs ID_FS_USAGE=filesystem .ID_FS_TYPE_NEW=xfs MAJOR=252 MINOR=16 DEVLINKS=/dev/disk/by-path/pci-0000:07:00.0 /dev/disk/by-path/virtio-pci-0000:07:00.0 /dev/disk/by-uuid/61c0b0c8-2f9e-4fbf-817d-eda65b0363d5 TAGS=:systemd: CURRENT_TAGS=:systemd:
