Robert White posted on Tue, 18 Nov 2014 17:29:12 -0800 as excerpted: > On 11/18/2014 07:42 AM, Phillip Susi wrote: > >> On 11/18/2014 1:16 AM, Chris Murphy wrote: >>> (stuff about UUIDs and LVM snapshots). > > (suggestion to use LVM paths instead). > > This is also an XFS+LVM+LVM_Snapshot problem going back to at least > 2009. It's inherent to the block-device-level snapshot phenomonia. > > q.v. http://www.miljan.org/main/2009/11/16/lvm-snapshots-and-xfs/ et al > > In XFS you attack the snapshot with a command to regenerate the UUID as > soon as you take the snapshot. I don't think there is a "regenerate all > my UUIDs" command for BTRFS.
Which was part of my point in my reply. Btrfs embeds the UUID in the metadata deeply enough that it's no simple task to simply change it to something else and be done. It's quite a complicated operation for any (future, none current) tool that attempts it, with the most likely candidate being an option to btrfs balance or the like, but even then, we're looking at a timescale of hours for spinning rust. So while it's possible in theory, in practice such a regenerate-all UUIDs command for btrfs isn't available yet, and given the time involved in rewriting all those metadata UUIDs to something else, during which the filesystem's in a critically unstable state, and the limited use-case with other alternatives, such a tool isn't all /that/ practical in any case. Making an entirely new btrfs and doing a btrfs send/receive for the duplicate, or using btrfs snapshots, is a more practical way to go. (Tho watch out for the implications of btrfs snapshots on nocow files!) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
