On Mon, 2023-10-02 at 14:49 -0400, Phillip Susi wrote:
>
> Looks that way. That would be how much space is left in the array
> that
> is not quite enough for another 4 MiB PE.
Good. Thanks for the sanity check.
> It shouldn't, but why bother?
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.
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 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.
Ultimately I should end up (prior to any attempt to rename) md1 with
sdd and sdc as an encrypted raid-1 array. The goal is to be able to
remove a disk from the raid array and safely
discard/return/recycle/etc. it knowing that it's content is relatively
secure.
The most problematic scenario of course is a disk dies and you want to
return it under warranty but you cannot access the disk to "scrub" it
and you either send it back with all kinds of sensitive data on it, or
you eat it.
Cheers,
b.
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 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/
