"Brian J. Murrell" <brian@xxxxxxxxxxxxxxx> writes: > Because I need to add another member to the array that is just slightly > smaller than the existing array. It's the same sized disk as what's in > the array currently but is itself an MD array with luks, which is > reserving it's own metadata region from the total disk making it > slightly smaller. You want to put an MD array inside of another MD array? Why? > So yes, ultimately I am going to have both an encrypted and unencrypted > member of this raid-1 array. At least until the encrypted member is > added and then I will remove the unencrypted member and add it to the > luks encrypted array. > > The general idea is to (safely -- as in be able to achieve in specific > sepearate steps that have a back-out plan) convert a non-encrypted > raid-1 array into an encrypted raid-1 array. > > So what I have right now is: > sdc 8:32 0 3.7T 0 disk > └─md0 9:0 0 3.7T 0 raid1 > ├─backups-backups 253:13 0 2.5T 0 lvm /.snapshots > ├─backups-borg 253:14 0 300G 0 lvm > └─backups-vdo--test 253:15 0 700G 0 lvm > └─vdo-backups 253:73 0 1.8T 0 vdo > sdd 8:48 0 3.7T 0 disk > └─md1 9:1 0 3.7T 0 raid1 > └─luks-backup 253:40 0 3.7T 0 crypt I would suggest that rather than > I am going to reduce the size of md0 so that it's the same size as md1, > then add md1 to md0 (so yes, I will have a raid-1 array with a raid-1 > member). Then I am going to remove md0 from the md1 array and then add > sdc to md1 so that md0 no longer exists and md1 is the primary raid-1 > array. Ideally, rename md1 to md0 once done but that's aesthetic. I would suggest instead that you add the luks volume as a new PV to your VG, then use pvmove to migrate all of your logical volumes from md0 to md1, then vgreduce md0 from the VG, stop md0, mdadm --zero-superblocks /dev/sdc, then add sdc to md1. _______________________________________________ linux-lvm mailing list linux-lvm@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
