On Mon, Mar 21, 2016 at 3:38 PM, Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx> wrote: > On Mon, Mar 21, 2016 at 03:26:30PM -0600, Chris Murphy wrote: >> At this point I'm skeptical this will work. Also, I'm not familiar >> with this overlay technique. I did look at the URL provided by >> Andreas, my concern is whether it's possible for the volume UUID to >> appear more than once to the kernel? > > Thanks for pointing out this issue, I'm not familiar with btrfs at all. > > Normally this would be a problem and you'd have to find some way > to change the UUID in the overlay or whatever, but if it's LUKS > encrypted that should solve the problem nicely, you just have to > stop the original RAID and close the original LUKS container > and then only open the one of the overlay. Yes hiding it with LUKS is the way to go here. There's no practical way to change the volume UUID as it's pervasive throughout the fs metadata, it's used everywhere. Changing it with btrfstune means completely rewriting out the entire fs metadata. It's the same now for XFS v5 which similarly uses fs volume UUID everywhere as a part of consistency checking, along with metadata checksumming. I'm not sure about the optional ext4 checksumming but I think it too is making wide use of fs volume UUID throughout metadata. So I think we have to be careful with multiple instances of UUID appearing and probably there need to be better checks in kernel code to avoid confusion. Btrfs is harder because it explicitly supports multiple devices, and the volume UUID correctly appears on all devices (as well as a unique device specific UUID). So it's used to seeing multiple instances of a volume UUID. But anyway, this is a side track topic. > > You should not assemble the original RAID anymore anyhow, anything > you write to the array at this point will likely only increase > damages. The overlay allows you to experiment in read-"write" > mode without actually changing anything on your disks. Agreed. If it turns out there are some repairs needed within Btrfs it's better with the overlay because it's unclear based on the errors thus far what repair step to use next, and some of these repair attempts can still sometimes make things worse (which are of course bugs, but nevertheless...) -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
