On 6/3/22 7:34 PM, Darrick J. Wong wrote:
> On Fri, Jun 03, 2022 at 11:14:13AM -0500, Eric Sandeen wrote:
>> On 5/19/21 10:22 AM, Lukas Herbolt wrote:
>>> 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>
>>> ---
>>> V2: Drop void casts and fix long lines
>>
>> Can we revisit this? I think it's a nice enhancement.
>>
>> The "nouuid" concern raised in the thread doesn't seem like a problem;
>> if someone mounts with "-o nouuid" then you'll see 2 different devices
>> mounted with the same uuid printed. I don't think that's an argument
>> against the patch. Printing the uuid still provides more info than not.
>
> Ok fair.
>
>> I, uh, also don't think the submitter should be required to do a tree-wide
>> change for an xfs printk enhancement. Sure, it'd be nice to have ext4
>> and btrfs and and and but we have no other requirements that mount-time
>> messages must be consistent across all filesystems....
>
> As you pointed out on irc, btrfs already prints its own uuids. So that
> leaves ext4 -- are you all planning to send a patch for that?
I threw one together, need to actually test and send it, but sure.
> (Otherwise, I don't mind this patch, if it helps support perform
> forensics on systems with a lot of filesystem activity.)
Cool, thanks.
>> Thanks,
>> -Eric
>>
>>>
>>> fs/xfs/xfs_log.c | 10 ++++++----
>>> fs/xfs/xfs_super.c | 2 +-
>>> 2 files changed, 7 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c
>>> index 06041834daa31..8f4f671fd80d5 100644
>>> --- a/fs/xfs/xfs_log.c
>>> +++ b/fs/xfs/xfs_log.c
>>> @@ -570,12 +570,14 @@ xfs_log_mount(
>>> int min_logfsbs;
>>>
>>> if (!(mp->m_flags & XFS_MOUNT_NORECOVERY)) {
>>> - xfs_notice(mp, "Mounting V%d Filesystem",
>>> - XFS_SB_VERSION_NUM(&mp->m_sb));
>>> + xfs_notice(mp, "Mounting V%d Filesystem %pU",
>>> + XFS_SB_VERSION_NUM(&mp->m_sb),
>>> + &mp->m_sb.sb_uuid);
>>> } else {
>>> xfs_notice(mp,
>>> -"Mounting V%d filesystem in no-recovery mode. Filesystem will be inconsistent.",
>>> - XFS_SB_VERSION_NUM(&mp->m_sb));
>>> +"Mounting V%d filesystem %pU in no-recovery mode. Filesystem will be inconsistent.",
>>> + XFS_SB_VERSION_NUM(&mp->m_sb),
>>> + &mp->m_sb.sb_uuid);
>
> sb_uuid is the uuid that the user can set, not the one that's encoded
> identically in all the cloud vm images, right?
Uhhh yeah I think so, and "sb_meta_uuid" is the internal one that remains
unchanged but I will double check because even though I wrote that, it's
un-intuitive. :(
Thanks,
-Eric
> --D
>
>>> ASSERT(mp->m_flags & XFS_MOUNT_RDONLY);
>>> }
>>>
>>> diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
>>> index e5e0713bebcd8..a4b8a5ad8039f 100644
>>> --- a/fs/xfs/xfs_super.c
>>> +++ b/fs/xfs/xfs_super.c
>>> @@ -1043,7 +1043,7 @@ xfs_fs_put_super(
>>> if (!sb->s_fs_info)
>>> return;
>>>
>>> - xfs_notice(mp, "Unmounting Filesystem");
>>> + xfs_notice(mp, "Unmounting Filesystem %pU", &mp->m_sb.sb_uuid);
>>> xfs_filestream_unmount(mp);
>>> xfs_unmountfs(mp);
>>>
>
>
