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.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
