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
