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

[Greg Troxel <gdt%lexort.com@localhost>]

Eugene Andrienko <evg.andrienko%gmail.com@localhost> writes:

> 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)

I am guessing here, but:

  - I'd expect that the underlying lv0, and cgd0 are now bigger.  You
    could use dd to read them to see.

  - there is a disklabel.  That's in sector 1 (0 boot block, 2-15
    bootstrap).  It is showing the same size as before because nothing
    changed it.

  - you could edit the disklabel and make the partition bigger (while
    starting in the same place!)

  - then resize_ffs will probably work

but realize that I am speculating there.

>>   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.

ah, that sounds  better.[q

>>   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.

For that box, the right call!