Introduction

One of my filesystem was far too big for his usage.
/var was sized to 10GB, but 5GB is far enough for the usage I have with this laptop.
So, I've decided to shrink it by 50% and to reallocate this free space to the filesystem just close to it : /tmp

I will describe all the actions and commands I've used.

Preparation tasks

At first, I have to look at the partition table.

Here is the output of it:

# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: INTENSO SSD 128G
duid: 81379a06de1dd84a
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 15566
total sectors: 250069680
boundstart: 64
boundend: 250067790
drivedata: 0

16 partitions:
#                size           offset  fstype [fsize bsize   cpg]
  a:          2097152               64  4.2BSD   2048 16384     1 
  b:          8641784          2097216    swap                    
  c:        250069680                0  unused                    
  d:          8388576         10739008  4.2BSD   2048 16384     1 
  e:         24623584         19127584  4.2BSD   2048 16384     1 
  f:          4194304         43751168  4.2BSD   2048 16384     1 
  g:          2097152         47945472  4.2BSD   2048 16384     1 
  h:         20971520         50042624  4.2BSD   2048 16384     1 
  i:          4194304         71014144  4.2BSD   2048 16384     1 
  j:          4194304         75208448  4.2BSD   2048 16384     1 
  k:        170664992         79402752  4.2BSD   2048 16384     1

My objective is to resize e: by 50%. The space create will be associate to d:.

By doing a simple calculation, e: should have a size of 24623584 / 2 = 12311792.
But, since I want to free the space for d:, I have to free it before it.
So, the offset for e: will be 43751168 - 12311792 = 31439376.

As you have noticed, this partition contains relevant data. So, I have to backup it up.

The command for such task is:

doas dump -0f /home/var.dump /var

Indeed, the /home partition is the only one we enough space (/var is 100MB in my case).

Now the preparation effort is done. I can now reboot and starting in a mode where filesystem will not be mounted.

Shrink the partition

I've decided to reboot with bsd.rd (ram disk) and, at the first screen I ask to go to the shell (type "s" at the prompt).

Once in the shell, I ask to use my keyboard: be because I'm using a azerty-Belgian keyboard.

kbd be

Now, the real task starts.

disklabel -E sd0

In the disklabel prompt, I type the following commands:

> d e
> a e
    [offset]: 31439376
    [size]: 12311792
    [FS Type]: enter
> q
    y

The first command delete the partition "e"
The 2nd command create a new partition called "e", and I provide the figures calculated in the preparation phase.
The last command quite and save the new layout. Disklabel asks if you are sure to save the new layout, just confirm by saying yes: y

Then we have to recreate the new filesystem on this partition:

newfs /dev/rsd0e

Now, I have to restore the previous dump of /var.

mount /dev/sd0e /mnt
mkdir /src
mount /dev/sd0k /src 
cd /mnt
restore -rf /src/var.dump
cd /
umount /mnt
umount /src
reboot

Done :-)

After a normal reboot to your OpenBSD system, you will see, via disklabel, that your new layout is taken in account :

16 partitions:
#                size           offset  fstype [fsize bsize   cpg]
  a:          2097152               64  4.2BSD   2048 16384     1 
  b:          8641784          2097216    swap                    
  c:        250069680                0  unused                    
  d:          8388576         10739008  4.2BSD   2048 16384     1 
  e:         12311792         31439376  4.2BSD   2048 16384 12958 
  f:          4194304         43751168  4.2BSD   2048 16384     1 
  g:          2097152         47945472  4.2BSD   2048 16384     1 
  h:         20971520         50042624  4.2BSD   2048 16384     1 
  i:          4194304         71014144  4.2BSD   2048 16384     1 
  j:          4194304         75208448  4.2BSD   2048 16384     1 
  k:        170664992         79402752  4.2BSD   2048 16384     1

Note: I do not know why the cpg is now 12958.
cpg is "cylinders per group". I do not find what is the real impact of this.
Maybe I should take more care to the offset and size values (multiple of Block size, ...)

Reallocated the free space to the partition d:

To perform this tasks, I do not take backups because this is /tmp in my case.

So, like previous, I prefer to reboot in Ram Disk and make sure that the disk sd0 is not in read/write.

Then, I ask bsd.rd to go to the shell par (type s). There I type the following commands:

kbd be
disklabel -E sd0

    > d d
    > a d
        [offset]: enter
        [size]: enter
        [FS Type]: enter
    > q
        y

In short, I delete the partition d:, and recreate it with the proposed offset and size. Since the gap created by the remove of d: is contiguous to the gap created by the removal of e:, I ave now a bigger disk capacity for d:

newfs /dev/rsd0d
reboot

I reboot the system in a normal OpenBSD system.
We can see, via disklabel, that all partitions are correctly defined.

16 partitions:
#                size           offset  fstype [fsize bsize   cpg]
  a:          2097152               64  4.2BSD   2048 16384     1 # /
  b:          8641784          2097216    swap                    # none
  c:        250069680                0  unused                    
  d:         20700360         10739000  4.2BSD   2048 16384 12958 # /tmp
  e:         12311792         31439376  4.2BSD   2048 16384 12958 # /var
  f:          4194304         43751168  4.2BSD   2048 16384     1 # /usr
  g:          2097152         47945472  4.2BSD   2048 16384     1 # /usr/X11R6
  h:         20971520         50042624  4.2BSD   2048 16384     1 # /usr/local
  i:          4194304         71014144  4.2BSD   2048 16384     1 # /usr/src
  j:          4194304         75208448  4.2BSD   2048 16384     1 # /usr/obj
  k:        170664992         79402752  4.2BSD   2048 16384     1 # /home

Note: here again the cpg value becomes 12958 for d:.

A df command shows the finale situation with the different filesystem's sizes:

e5450:~$ df -h
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/sd0a     1005M    201M    754M    21%    /
/dev/sd0k     80.1G   11.1G   65.0G    15%    /home
/dev/sd0d      9.7G    1.5M    9.2G     0%    /tmp
/dev/sd0f      2.0G    1.1G    805M    58%    /usr
/dev/sd0g     1005M    248M    707M    26%    /usr/X11R6
/dev/sd0h      9.8G    5.7G    3.6G    61%    /usr/local
/dev/sd0j      2.0G    2.0K    1.9G     0%    /usr/obj
/dev/sd0i      2.0G    2.0K    1.9G     0%    /usr/src
/dev/sd0e      5.8G    108M    5.4G     2%    /var

Conclusion

Shrinking a filesystem is not too complicated if we take care of few elements.
I have to investigate in order to understand why the cpg parameter has changed and if it can stay as it is or not.