On Thu, Nov 03, 2022 at 02:32:52PM +0100, 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? Don't like it. Emitting the UUID on the fs mount/unmount log message is a trivial change that has zero impact on anything as well as being really easy for log scrapers to deal with. Screwing around with udev to manage and/or find this correlationi is ... unnecssarily awful. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
