Re: How to change BTRFS filesystem UUID

[Jiri Kanicky <j@ganomi.com>]

Hi,

Thanks for the detailed information. The data were not corrupted, so I 
could copy them to a new BTRFS partition.

Here is what happened exactly.

VM with BTRFS filesystem running on XenServer. The VM disk is a VHD 
stored on NFS storage. NFS storage ran out of space, and I found the 
BTRFS in RO mode. I could not remount it as RW after increasing the 
storage space. I rebooted the VM and the VM was not able to boot 
anymore. There were many lines during boot reporting "btrfs open_ctree 
failed" and the boot ended up in dracut mode.

I booted from CD and find out that I can mount the BTRFS filesystem and 
all data are there.

I created a new disk with BTRFS filesystem, copied all the data on it, 
and that new disk booted fine. (I actually used a disk from my template, 
so that is where the same BTRFS UUID comes from. But this was not the 
real issue. I copied the data on EXT4 disk first and then to the new 
disk to avoid having same BTRFS UUIDs. I will try changing the UUIDs as 
suggested later.)

In summary, I think that BTRFS was not able to recover from the scenario 
explained above. VMs with EXT4 could boot normally.

Regards,
Jiri


On 28/12/2015 10:13 AM, Hugo Mills wrote:
> On Mon, Dec 28, 2015 at 12:01:39AM +0100, Christoph Anton Mitterer wrote:
>> On Mon, 2015-12-28 at 02:27 +1100, Jiri Kanicky wrote:
>>> Thanks for the reply. Looks like I will have o use some newer
>>> distro.
>> As it was already said... btrfs may even corrupt your filesystem if
>> colliding UUIDs are "seen".
>>
>> At least to me it's currently unclear what "seen" exactly means...
>> actually trying a mount, or already when just a device with colliding
>> IDs appear.
>     The damage happens on (or after) mount. Until that point there's no
> danger.
>
>     The OS (usually udev) will run btfs dev scan when a new block
> device is detected, and it tells the kernel that there's a btrfs
> filesystem with a particular UUID on a particular block device.
>
>     The kernel uses this information to decide which devices to include
> when it assembles a filesystem. If you have two devices where there
> should be only one (particularly if the data on the two was similar
> but has now diverged), then the kernel can end up writing to one or
> other device arbitrarily, possibly having read state from the other
> one, and things screw up rather fast.
>
>     Hugo.
>
>> So whenever you do your recovery works, make sure that there's never a
>> moment where more than one btrfs block device appears with the same
>> UUID.
>> Even when it's just for some seconds it may already cause corruption.
>>
>>
>> Cheers,
>> Chris.
>
>