Re: BTRFS messes up snapshot LV with origin

[Phillip Susi <psusi@ubuntu.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/19/2014 1:33 PM, Chris Murphy wrote:
> Thin volumes are more efficient. And the user creating them doesn't
> have to mess around with locating physical devices or possibly
> partitioning them. Plus in enterprise environments with lots of
> storage and many different kinds of use cases, even knowledable
> users aren't always granted full access to the physical storage
> anyway. They get a VG to play with, or now they can have a thin
> pool and only consume on storage what is actually used, and not
> what they've reserved. You can mkfs a 4TG virtual size volume, 
> while it only uses 1MB of physical extents on storage. And all of 
> that is orthogonal to using XFS or Btrfs which again comes down to 
> use case. And whether I'd have LVM mirror or Btrfs mirror is again 
> a question of use case, maybe I'm OK with LVM mirroring and I just 
> get the rare corrupt file warning and that's OK. In another use 
> case, corruption isn't OK, I need higher availability of known
> good data therefore I need Btrfs doing the mirroring.

Correct me if I'm wrong, but this kind of setup is basically where you
have a provider running an lvm thin pool volume on their hardware, and
exposing it to the customer's vm as a virtual disk.  In that case,
then the provider can do their snapshots and it won't cause this
problem since the snapshots aren't visible to the vm.  Also in these
cases the provider is normally already providing data protection by
having the vg on a raid6 or raid60 or something, so having the client
vm mirror the data in btrfs is a bit redundant.




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUbO4nAAoJEI5FoCIzSKrwl/QIAJ7arJ0ZXVc16pBRjE2F66uV
GAOhatdx8pLhGey6by+gV8Ltvx4bK3BG40dkvQIM9RN9UFC5vofQ4FnzIn1nfXZB
qyyITE2mF+lE3RNCb8ZKxwG58rfa9NOModPCeNVFWkS6+fyyhGY23sliWbVO6b15
w6BD5xu/Pp7Fhgkx81AL07XpusR9c8pKZd8ZHw4nozFHw20+13XuL+2g8axpZS+O
Xd9W5GRlC+0k9jQ0q9xGi1jh6QpjMSWVj54MNS5jRubsY65TtmFPkdvgaMGD4U5k
bADSEUMfij9NRMw8VwA4ik/JEi1IbukD4u1geKeZTowMGXReel2RimeA/PhFYcc=
=tmDI
-----END PGP SIGNATURE-----