On Fri, Mar 07, 2025 at 08:47:08AM +0100, Kjetil Torgrim Homme wrote: > to. den 06. 03. 2025 klokka 10.39 (-0800) skreiv Darrick J. Wong: > > 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 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 a change to xfs(5) is appropriate, because sysadmins don't necessarily I don't think it's necessary for the xfs_admin manpage because then we'd have to explain that it can fail if the log is dirty (e.g. due to snapshotting), that it's necessary to mount to replay the log, and that there's a corner case where mount fails due to snapshots having the same uuid... which is already going into the advisory text below. > > > > 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." > > I like these texts, simple and plain spoken. I think my extra text for > xfs(5) is appropriate in addition to your change, the xfs_admin(8) > addition is less obvious. <nod> patch soon. --D > > -- > venleg helsing, > Kjetil T.
