Re: Is it possible to enlarge cgd-encrypted partition?

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> From: Eugene Andrienko <evg.andrienko%gmail.com@localhost>
> Date: Mon, 21 Sep 2026 15:51:00 +0300
> 
> Hello! I'm planning a disk configuration for my home NAS and stuck with
> the subject. Maybe someone already have the experience or an expertise
> to be able to say is a next thing possible or not?
> Sadly, I didn't found (or didn't understood) the answer while reading
> The Guide and man pages.
> 
> The existing system description:
> 
> 1) I have a disk #1 with a big partition (rraid0b) used as a physical
>    volume for a volume group (vg0), for LVM.
> 2) On top of vg0 there is a logical volume lv0, which takes all
>    available space on the rraid0b.
> 3) On top of the lv0 there will be encrypted CGD device. The resulting
>    cgd0a will be formatted in FFSv2.

If you were doing this afresh, I would suggest you do it the other way
around: configure cgd0 on raid0b, and add cgd0 as pv to vg0; then to
expand it, you can configure cgd1 on raid1b, and add cgd1 as a pv to
vg0.  (Or, push further even down: configure cgd0 on wd0, cgd1 on ld1,
cgd2 on sd2, ..., and raid0 on {cgd0,cgd1}, raid1 on {cgd2,cgd3}, and
so on.)

You can either make the cgd0 and cgd1 keys entirely independent with
an independently generated parameters file per volume, or derive them
as subkeys from a common primary key using the `shared' directive and
use an independent random 32-byte `info' string for each disk (see the
cgdconfig(8) man page).

The reason I suggest this is so that you can _recycle_ each disk
independently -- to securely erase it when you recycle it, you only
need to erase _that disk's_ parameters file (at which point the
ciphertext on the disk will become unreadable).  (There's a
performance tradeoff: if you are mirroring two cgds, instead of doing
cgd on a mirror of two disks, you do 2x encryption.)

The way you have done it, you can't securely erase _one_ disk without
erasing _all_ of them.  But if that's the setup you already have --
unless you have spare capacity to confidently back everything up and
restore it -- so be it.

> What I'm trying to achieve:
> 
> 4) Buy a big disk #2 and add it to the volume group vg0 with the help of
>    lvm vgextend command. Then enlarge the logical volume lv0 to the size
>    at near rraid0b_size + big_disk_no2_size (with the help of lvm
>    lvextend command).
> 5) ??? do something with cgd ???
> 6) Enlarge FFSv2 with the help of resize_ffs command.
> 7) Don't lost my files during the process.
> 
> And the question is for the item #5: what to do with the CGD device? If
> the size of underlying device (lv0) was increased, will it be possible
> to simply resize FFSv2 on the cgd0a to the new size?
> 
> Or some unknown for me commands are necessary to enlarge the cgd device
> after lv0 size was increased?

There is generally nothing needed to extend a cgd volume: the
encryption schemes used by cgd depend only on the key and sector
numbers, not on the total number of sectors in the volume, and there
is no metadata stored on the volume itself.  So as long as the disk
sectors stay in their original positions and you just add more at the
end -- as lvm lvextend does -- you should be fine.

But first, you should test this with a small model of your setup,
because it's there's a lot of moving parts.  Instead of testing on a
whole disk, you can just create a regular file and configure it with
vnd(4) as a disk device:

dd if=/dev/zero of=./modeldisk0 bs=1m count=128
vnconfig vnd0 ./modeldisk0
lvm pvcreate /dev/vnd0
lvm vgcreate vg0 /dev/vnd0
lvm lvcreate -L 96m vg0 lv0
cgdconfig cgd0 lv0 cgd0.params
dd if=/dev/zero of=/dev/rcgd0 bs=1m count=1
newfs cgd0a
mount /dev/cgd0a /mnt
touch /mnt/hello
echo foo >/mnt/bar
mkfifo /mnt/baz
(cd /mnt && mtree -c) | mtree -C -K sha256 >/var/tmp/mtree.out
umount /mnt

Make sure this matches your existing disk topology.  Then add a new
one and resize the file system:

dd if=/dev/zero of=./modeldisk1 bs=1m count=128
vnconfig vnd1 ./modeldisk1
lvm pvcreate vnd1
lvm vgextend vg0 /dev/vnd1
lvm lvextend -L 192m lv0

At this point you may need to unconfigure and reconfigure cgd0 in
order to make it recognize the expanded disk size -- it likely caches
the underlying medium's size and I'm not sure there's a mechanism for
the underlying medium to notify it of a change.  You may even need to
unconfigure it before lvextend and reconfigure it after lvextend.  You
may also need to edit the disklabel to reflect the updated size.

Then you should be able to resize_ffs cgd0a, fsck -p, mount, and check
that all your files are in place:

(cd /mnt && mtree) </var/tmp/mtree.out