XFS UUID / Using DD to clone a disk / Filesystem has duplicate UUID can't mount

[tr0910]

I must be doing something stupid. 

==============

To convert my backup servers from RFS to XFS I have use this approach a number of times without any issue.  However this time, it failed. 

dd if=/dev/sdX of=/dev/sdY bs=32M

After dd was finished, the disk was pulled and moved to another server and hot plugged and mounted via unassigned devices.  The other times I have rebooted after doing an RFS->XFS conversion via DD, but since this is a different server, and was running processes that I didn't want to interrupt, I did it this way.  (this disk is likely a copy of a copy that originally came from this other server)

 

The disk does not mount and we get the following log entries for unassigned devices...

 

Jun 21 23:28:49 Adding disk '/dev/sdg1'...
Jun 21 23:28:49 Mount drive command: /sbin/mount -t xfs -o rw,noatime,nodiratime '/dev/sdg1' '/mnt/disks/WDC_6128'
Jun 21 23:28:49 Mount of '/dev/sdg1' failed. Error message: mount: wrong fs type, bad option, bad superblock on /dev/sdg1,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

and syslog has the mount error:

Jun 21 23:42:57 Kim kernel: scsi 2:0:0:0: Direct-Access ATA WDC WD30EZRX-00D 0A80 PQ: 0 ANSI: 5
Jun 21 23:42:57 Kim kernel: sd 2:0:0:0: Attached scsi generic sg7 type 0
Jun 21 23:42:57 Kim kernel: sd 2:0:0:0: [sdg] 5860533168 512-byte logical blocks: (3.00 TB/2.73 TiB)
Jun 21 23:42:57 Kim kernel: sd 2:0:0:0: [sdg] 4096-byte physical blocks
Jun 21 23:42:57 Kim kernel: sd 2:0:0:0: [sdg] Write Protect is off
Jun 21 23:42:57 Kim kernel: sd 2:0:0:0: [sdg] Mode Sense: 00 3a 00 00
Jun 21 23:42:57 Kim kernel: sd 2:0:0:0: [sdg] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jun 21 23:42:57 Kim kernel: sdg: sdg1
Jun 21 23:42:57 Kim kernel: sd 2:0:0:0: [sdg] Attached SCSI disk
Jun 21 23:43:28 Kim kernel: XFS (sdg1): Filesystem has duplicate UUID 822e2574-c2ee-4fcf-a00b-38a4acbc4865 - can't mount
Jun 21 23:13:49 Kim kernel: XFS (sdg1): Filesystem has duplicate UUID 822e2574-c2ee-4fcf-a00b-38a4acbc4865 - can't mount

 

Moving the disk back to the original server where it was converted via dd and it hot-plugs and mounts via unassigned devices as a new XFS disk without issue.  However on the original server it seems to conflict with disk4 (disk4 was the source copy of the dd command so this makes sense), and disk4 shows unmountable if this disk is mounted via unassigned devices.  Unmounting this disk allows the array to start and disk4 is good, but now this disk won't mount.

 

Jun 22 16:12:49 Server1 kernel: XFS (sdb1): Filesystem has duplicate UUID 822e2574-c2ee-4fcf-a00b-38a4acbc4865 - can't mount

 

I guess I need to understand the XFS UUID better.  What is XFS UUID and how is it generated?  Can it be duplicated by DD?

 

More details here:  https://lime-technology.com/forum/index.php?topic=47987.msg478929#msg478929

 

[John_M]

Using dd to copy a disk does just that, byte for byte, including the UUID. Does this link help at all?

 

[tr0910]

Yes, that looks like it should help, but I tried it and now the uuid change process is not working...

 

root@Server1:~# xfs_admin -U generate /dev/sdb1
xfs_admin: only 'rewrite' supported on V5 fs

 

This UUID change limitation is acknowledged here

 

https://bugzilla.redhat.com/show_bug.cgi?id=1233220

[John_M]

My suggestion then is not to use dd on XFS filesystems. More information here, especially the following paragraph:

 

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.

[tr0910]

Latest beta 6.2b23 has the xfs_admin upgraded to 4.3 and it will now generate a uuid without error.

 

root@Tower:~# xfs_admin -U generate /dev/sdd1
Clearing log and setting UUID
writing all SBs
new UUID = b8cacfbe-97c3-40fa-983d-b422c4c52edf