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

[Eugene Andrienko <evg.andrienko%gmail.com@localhost>]

Greg Troxel <gdt%lexort.com@localhost> writes:

> I haven't done this, but my reaction is that you are walking into
> not-well-traveled territory and there is considerable risk.

Nice! I made some experiment and found that making LVM logical volume,
encrypting it with CGD and then enlarging underneath LVM logical volume
doesn't work as expected.

    PREREQS:

In the test I created a 901.51 GiB logical volume from one "physical"
volume /dev/rraid0b:
# lvm pvdisplay
  PV Name               /dev/rraid0b
  PV Size               901.51 GiB / not usable 1.62 MiB
# lvm vgdisplay
  VG Name               vg0
  VG Status             resizable
  VG Size               901.51 GiB
# lvm lvdisplay
  LV Name                /dev/vg0/lv0
  VG Name                vg0
  LV Size                901.51 GiB

Then, I created CGD device and make an FFSv2 on it:
# disklabel -C /dev/cgd0a
bytes/sector: 512
sectors/track: 2048
tracks/cylinder: 1
sectors/cylinder: 2048
cylinders: 923148
total sectors: 1890607104
#        size    offset     fstype [fsize bsize cpg/sgs]
 a: 923148/0/0     0/0/0     4.2BSD      0     0     0  # (Cyl.      0 - 923147)
 d: 923148/0/0     0/0/0     unused      0     0        # (Cyl.      0 -
 923147)

    THE TEST:

I took the unnecessary USB drive (at near 8 GB) and added it to the
volume group vg0 and resized the logical volume lv0 accordingly:
# lvm vgdisplay
  VG Name               vg0
  VG Status             resizable
  VG Size               908.96 GiB
# lvm lvresize -L+7.45G vg0/lv0
# lvm lvdisplay
  LV Name                /dev/vg0/lv0
  VG Name                vg0
  LV Size                908.96 GiB

Then I decrypted the /dev/cgd0a again, looked to the partitions list -
nothing changed:
bytes/sector: 512
sectors/track: 2048
tracks/cylinder: 1
sectors/cylinder: 2048
cylinders: 923148
total sectors: 1890607104
#        size    offset     fstype [fsize bsize cpg/sgs]
 a: 923148/0/0         0     4.2BSD      0     0     0  # (Cyl.      0 - 923147)
 d: 923148/0/0         0     unused      0     0        # (Cyl.      0 -
 923147)

Also, I tried to use ffs_resize - it also changed nothing, the size of
decrypted disk was still the same as before (at near 888 GB):
Filesystem     Size   Used  Avail %Cap Mounted on
/dev/cgd0a     888G   8.0K   843G   1% /mnt

>   do you have multiple, good, offline
>   backups of all this data?   Have you tested them?

Yes, but it is kinda crazy - multiple DVD disks, because of financial
problems. Hope, in the future I'll be able to buy a second-hand streamer
and a bunch of LTO tapes to make it in proper way, when my NAS contents
will become too big to save to DVDs.

>   Think about whether you want/need RAID of some sort.  A fileserver
>   with multiple disks that are basically RAID-0 (concatenated) means
>   that if either breaks, you lose your filesystem.  In the old days I
>   used RAID-1 with raidframe, which has saved me twice personally and I
>   don't remember how many times at work

I omitted it in my original message, but the "disk #1" mentioned in it,
is basically a RAID-1 array, made with raidframe too. The second disk
will be a RAID-1 too.

>   Think about zfs.  ZFS on NetBSD really only works on NetBSD 11 and
>   current, unless maybe you have vastly more memory than you need, or
>   you never use a program that does write via mmap.  I am unclear on zfs
>   encryption.  I am unclear on if creating a huge zvol and using cgd
>   works.

I thought about it, but in my little "selfhosting experiments" I'm using
a low-cost Intel Atom based machine with 2 GB of RAM. It is able to run
a tons of services (PostgreSQL, Asterisk, Nginx'es, etc) but I found
that under the heavy write operations to ZFS volume the RAM ends very
fast and system starts to kill the other processes :-(.

So, I decided to evade ZFS and use another, not so memory-hungry,
approaches.

> I realize disk prices are crazy.

Indeed ;-(.

-- 
Eugene Andrienko