Re: nouuid hint in kernel message?

["Darrick J. Wong" <djwong@kernel.org>]

On Thu, Mar 06, 2025 at 12:36:34PM +0100, Kjetil Torgrim Homme wrote:
> to. den 06. 03. 2025 klokka 11.00 (+0100) skreiv Carlos Maiolino:
> > On Thu, Mar 06, 2025 at 12:46:23AM +0100, Kjetil Torgrim Homme wrote:
> > > hey people, thank you for XFS!
> > > 
> > > tl;dr: consider changing the kernel message "Filesystem has duplicate
> > > UUID - can't mount" to include a hint about the existence of the nouuid
> > > mount option.  perhaps append " (use -o nouuid?)" to message?
> > 
> > This looks good at first, but adding a message like this has a big down
> > side IMHO. This leads users to simply attempt to do that even in cases when they
> > shouldn't.
> > 
> > As an example, in a common multipath environment with dm-multipath, an user
> > might accidentally attempt to mount both individual paths to the same device,
> > and this uuid duplicate check protects against such cases, which might end in
> > disaster.
> 
> makes sense.
> 
> 
> > On a mid term here, I think we could improve xfs(5) to include a bit more
> > information about duplicated uuids.
> > 
> 
> current text:
> 
>    Each XFS filesystem is labeled with a Universal Unique Identifier
>    (UUID).  The UUID is stored in every allocation group header and is used
>    to help distinguish one XFS filesystem from another, therefore you
>    should avoid using dd(1) or other block-by-block copying programs to
>    copy  XFS  filesystems.   If two XFS filesystems on the same machine
>    have the same UUID, xfsdump(8) may become confused when doing
>    incremental and resumed dumps.  xfsdump(8) and xfsrestore(8) are
>    recommended for making copies of XFS filesystems.
> 
> perhaps add a sentence at the end of that, "To mount a snapshot of an
> already mounted filesystem, use mount option \fBnouuid\fR."
> 
> possibly also something about this in xfs_admin(8)?
> 
> current text:
> 
>        -U uuid
>               Set  the  UUID  of the filesystem to uuid.  A sample UUID
>               looks like this: "c1b9d5a2-f162-11cf-9ece-0020afc76f16".
>               The uuid may also be nil, which will set the filesystem
>               UUID to the null UUID.  The uuid may also be generate,
>               which will generate a new UUID for the filesystem.  Note
>               that on CRC-enabled  filesystems,  this will set an
>               incompatible flag such that older kernels will not be
>               able to mount the filesystem.  To remove this
>               incompatible flag,  use restore, which will restore the
>               original UUID and remove the incompatible feature flag
>               as needed.
> 
> suggested addition: "A transient snapshot which conflicts with a mounted
> filesystem can alternatively be mounted with the option \bBnouuid\fR."
> 
> what do you think?

I think we ought to fix the informational messages in xfs_db:

"ERROR: The filesystem has valuable metadata changes in a log which
needs to be replayed.  Mount the filesystem to replay the log, and
unmount it before re-running xfs_admin.  If the filesystem is a snapshot
of a mounted filesystem, you may need to give mount the nouuid option.
If you are unable to mount the filesystem, then use the xfs_repair -L
option to destroy the log and attempt a repair.  Note that destroying
the log may cause corruption -- please attempt a mount of the filesystem
before doing this.

and xfs_repair:

"ERROR: The filesystem has valuable metadata changes in a log which
needs to be replayed.  Mount the filesystem to replay the log, and
unmount it before re-running xfs_repair.  If the filesystem is a
snapshot of a mounted filesystem, you may need to give mount the nouuid
option.  If you are unable to mount the filesystem, then use the -L
option to destroy the log and attempt a repair.  Note that destroying
the log may cause corruption -- please attempt a mount of the filesystem
before doing this."

Thanks for reporting this on the list so we can have a discussion, btw.

--D


> 
> -- 
> venleg helsing,
> Kjetil T.
>