Re: BTRFS messes up snapshot LV with origin

[Duncan <1i5t5.duncan@cox.net>]

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