On 11/22/2014 11:52 AM, Chris Murphy wrote:
I don't know how to fix this but I've convinced myself there's at
least a small problem. And not just with LVM snapshots as in the
originating thread.
Yes.
You also run into this problem if you use multipath hardware but haven't
configured multipath support to be transparent.
In any system, when you mix layers of abstraction you get problems.
LVM snapshots make "the same disk blocks" appear in multiple places but
don't actually present "the same disk blocks" since writes to "those
blocks" will cause COW divergence.
This violates the Universally Unique constraint of the UUID promise.
None of these are problems with the respective systems working at their
respective jobs, they are inherent problems with the fact that a servant
can not serve two masters.
As far as the parentage trees of subvolumes... I've been trying to get
_anybody_ on here to recognize the problems already inherent in that
system as implemented. Take a couple snapshots of a subvolume, and then
send those subvolumes to another file system with send/receive, and then
do "btrfs subvolume list -u -q" on the two filesystems and tell me that
mess makes sense. Or try to recreate a subvolume from its snapshot in a
way that doesn't shatter the relationships in your backup scheme. (I'm
researching for a couple patches but I'm not expecting a warm reception
given the silence to date).
So yea, UUID plus copy plus mirror plus snapshot equals a trip to caveat
city.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
