On 12/14/2017 03:58 PM, Andrew Schoen wrote: >>> It's worth mentioning that the "new" way for new ceph-volume OSD >>> deployments will also be using LVM, and (presumably?) allow layering >>> dm-crypt on top of an LV--not just a PV or raw device. So this is more a >>> question of what, clean slate, we want to do to deploy dm-crypt when the >>> end result that we're after is an LV to feed to bluestore or filestore. >>> I'm not sure how/where LUKS fits in in the LVM world... >> >> I think LUKS fits in LVM world quite well. >> >> Standard Fedora (and most other distors as well) install stacks LVM over LUKS >> (so you activate only one encrypted device and then the partitioning is up to LVM. >> Also LVM metadata are then encrypted.) >> >> You can of course stack LUKS over LV as well, but for example LV resize >> will be two-step operation (well, fsadm can automate it but it is still two-steps). > > Would this be the only downside to LUKS on LVM? This approach is nice > for ceph-volume > because we need to be able to encrypt anything given to us, which is > often times a LV. > > The LVM on LUKS approach also makes it more difficult to expand the > underlying vgs and span > lvs across many disks. If I'm understanding correctly. LUKS over LV should work perfectly fine, so if you have more arguments for this approach, than use it. (I think you can still have more LUKS devices that contains more PVs to one VG in LVM, byt it could be more complicated to maintain.) So I am probably just a little bit confused from the approach that there can be more OSDs spanning one physical device. If it is common now, then I guess LV is just an equivalent of OSD on a physical hotplugged device and you solution makes perfect sense. Milan -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
