-----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----- -- 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
