linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: "Brian J. Murrell" <brian@interlinx.bc.ca>
To: linux-lvm@redhat.com
Subject: Re: [linux-lvm] Is MD array (containing a PV) reducible?
Date: Mon, 02 Oct 2023 15:21:17 -0400	[thread overview]
Message-ID: <f510c5de56008c4c74a7d22f267ab2f8e2f37c96.camel@interlinx.bc.ca> (raw)
In-Reply-To: <87pm1wn9j0.fsf@vps.thesusis.net>


[-- Attachment #1.1: Type: text/plain, Size: 2605 bytes --]

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 #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 202 bytes --]

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

  reply	other threads:[~2023-10-02 19:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-02 16:03 [linux-lvm] Is MD array (containing a PV) reducible? Brian J. Murrell
2023-10-02 18:49 ` Phillip Susi
2023-10-02 19:21   ` Brian J. Murrell [this message]
2023-10-02 20:02     ` grumpy
2023-10-02 20:48     ` Phillip Susi
2023-10-02 22:50       ` Brian J. Murrell
2023-10-02 23:37         ` Phillip Susi
2023-10-03 22:23           ` Brian J. Murrell
2023-10-04 13:18             ` Phillip Susi
2023-10-04 17:59               ` Brian J. Murrell
2023-10-05 12:16                 ` Phillip Susi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f510c5de56008c4c74a7d22f267ab2f8e2f37c96.camel@interlinx.bc.ca \
    --to=brian@interlinx.bc.ca \
    --cc=linux-lvm@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).