Initial situation: LVM under NetBSD – theoretically yes, practically difficult
NetBSD has had a Device Mapper for several years
in the kernel and also brings the well-known Linux tools (dmsetup,
lvm) in user space. In theory, everything you need is there
LVM knows – volumes, snapshots, flexibility.
In practice, however, there is a problem: the implementation is not yet there
complete, and worse – there are reproducible ones
System freezes as soon as there is a logical volume
FFSv2 file system is located and you can use it with FSS
Creates a snapshot, for example to create a consistent backup with dump
during ongoing operations.
This isn’t a complaint - NetBSD is continually evolving further. I decided to look at the matter in more detail to investigate, check bug reports or, if necessary, create new ones. Already In 2017 I had… Mailing list archive similar observations have been reported - apparently more of a borderline case.
What I actually wanted
My requirements are modest: I want block storage for Deploy different Xen-DomU VMs as close as possible to the hardware – high-performance, comprehensible, with manageable overhead. A look in my article Storage performance in the practical test shows that I I have been concerned with the performance aspects for a long time.
Because I have a hard time predicting the future memory requirements of the VMs I would like to let these volumes grow as needed – classic LVM use case. Unfortunately, the current one is NetBSD LVM implementation is not an option for this.
CCD as a silent alternative
Then I remembered an old friend: CCD – Concatenated Disk Device. A simple, tried and tested concept right in the kernel. None Daemons, no metadata, no black box magic.
With CCD you can several without additional software Combine GPT partitions into a block device. This leaves pass through to Xen without any problems - a feature that is amazing feels modern even though it is ancient.
The best thing about it: You can enlarge it at any time by just added more GPT partitions and rebuilt the CCD configured. This only causes a brief interruption, but it is Completely acceptable for my use case.
Initial tests showed: The process is robust, high-performance and – im In contrast to LVM – completely inconspicuous when snapshotting with FSS. With that My future stack for the home server was basically clear.
All that was missing was a tool
What bothered me wasn’t the technology, but the workflow. CCD is
minimalistic – you edit /etc/ccd.conf, configure devices
manually and has to remember names and wedges. For the productive
In everyday life, I wanted a tool that would make the whole thing a little more comfortable.
This is how ccdtool was born - a small shell script that is similar to LVM Provides commands for CCD:
#!/bin/sh
# ccdtool - LVM-like management utility for NetBSD CCD volumes
# Provides simple commands to create, extend, destroy and inspect CCD devices
# using human-friendly aliases instead of raw device names.
#
# Copyright (c) 2025 Matthias Petermann <matthias@d2ux.net>
# License: MIT
With commands like:
ccdtool create vmstore wd2 200G
ccdtool extend vmstore wd3 200G
ccdtool show vmstore
ccdtool destroy vmstore
…GPT partitions are created automatically, CCD configurations
expanded or deleted and alias names maintained in a mapping file
– without ever having to touch /etc/ccd.conf.
A complete source code can be found in the repository:
👉 forge.ext.d2ux.net/Polaris/toolbox
Advantages of the approach
The charm lies in the simplicity:
- no metadata layer
- no additional dependencies
- no magic volume groups
- comprehensible configurations
Anyone who wants can use the generated CCD entries or GPT labels at any time inspect. The system remains testable, portable and script-friendly – typical NetBSD.
Another advantage: FSS + dump works on the files created in this way CCD devices are absolutely stable – even with large file systems. Exactly that, which LVM unfortunately does not currently deliver reliably.
Outlook: Integration into sysadm
The ccdtool is not a one-off project, but part of a larger one
plan. In the medium term, it will be converted into a modular tool suite called
sysadm rise - a collection of lightweight shell scripts,
which is based on a standard NetBSD installation and virtualization
Make system operation accessible to users who are less familiar with the system.
And to be honest: It should also save me from making mistakes –
Because nothing is more embarrassing than accidentally using the wrong ccdconfig -u to catch ;-)
Conclusion:
ccdtoolshows that you can use the classic NetBSD on-board resources – CCD, GPT and a little shell – surprisingly modern can implement workflows. No overhead, no magic, none Complexity - just clear tools that do what they’re supposed to do. Sometimes the future lies in the past.
Image credit: The NetBSD logo is a registered trademark of the NetBSD Foundation, Inc. Use in the context of editorial reporting in accordance with the Logo Use Guidelines.