The first release of Blockstor is now available — an open-source distributed block storage management system for Kubernetes that provides data replication over DRBD. Blockstor is REST API compatible with LINSTOR and can seamlessly work with the existing client ecosystem, including the linstor command-line utility, CSI driver, Piraeus operator, ha-controller, and the golinstor library. The project is a fully standalone (clean-room) implementation in Go, without using the original source code. The code is distributed under the Apache 2.0 license and is developed within the Cozystack platform (CNCF Sandbox project).
The project author is Andrey Kvapil (@kvaps), founder of Cozystack and a participant in the non-profit organization Piraeus, which develops the LINSTOR operator and CSI driver for Kubernetes. The author is known in the Kubernetes community as a promoter of LINSTOR and has presented technical reports on the subject multiple times. Initially, the development was conceived as a small 'Friday' initiative, but eventually turned into approximately 20 days of continuous work. Currently, the project is being developed as a research project, but in the future, it is considered a potential replacement for LINSTOR as the default storage system in Cozystack.
The reasons for creating the new project include difficulties in maintaining the original project and transferring changes to the main project, as well as architectural limitations of LINSTOR. The original project uses a 'request-based' real-time processing model that shows issues at scale, while the declarative reconciliation approach of Kubernetes and the controller-runtime framework, according to the author, is significantly better suited for building distributed systems.
Unlike LINSTOR, Blockstor's architecture is entirely based on the Kubernetes controller-runtime approach. The configuration and current state of the system are represented as Kubernetes CRD objects, and the system is not designed to operate outside of a Kubernetes cluster.
The main features of Blockstor include:
- Replicable volumes over DRBD based on LVM, LVM-thin, ZFS, ZFS-thin, and file backends.
- Automatic placement of replicas considering zones, node characteristics, and 'replicas-on-different' rules.
- Support for TieBreaker, quorum, and resizing volumes without downtime.
- The ability to operate without DRBD in local mode (single-replica diskful) or without-disk storage.
- Volume encryption through LUKS.
- Snapshot support: creation, rollback, cloning, and recovery as a new resource.
- Transferring snapshots within the cluster via zfs send/recv and thin-send-recv.
- Creating storage pools from physical disks.
- Container images built for different architectures (linux/amd64 and linux/arm64), published in GHCR.
A key feature of the project was the active use of AI tools during development. Almost all code was prepared using Claude Code (Opus 4.7 model) from Anthropic. Development was conducted almost round the clock for about 20 days. At times, up to 60 AI agents worked simultaneously, and the overall development dialogue involved about 1320 requests from the author and around 36,000 responses from the model within one continuous session.
The outcome was 1500 commits, with 83,000 lines of code for implementation and another 137,000 lines of code for tests. Preliminary estimates suggest that approximately 18.9 billion tokens were used, and the equivalent cost of such volume based on API rates would be about 40,000 dollars.
The author initially expected a nearly fully autonomous development led by the AI model; however, the complex logic of DRBD required constant human involvement. The most challenging scenarios involved synchronization states of DRBD, working with the Generation Identifier (GI), skipping the initial synchronization, and handling split-brain scenarios.
Since the original LINSTOR is distributed under the GPL license, its code could not be used directly. The main implementation was based on an analysis of API contracts, the behavior of utilities, the Python client for LINSTOR, and other compatible licensed projects, including piraeus-operator and CSI driver.
In the most complicated cases, a role-splitting scheme for AI agents was applied: one agent analyzed the original LINSTOR code and formed a textual specification of behavior, after which another agent implemented functionality strictly according to this specification without directly copying the original code. Due to the lack of open tests from the original project, the test base had to be formed independently.
Source: opennet.ru
