[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-82015":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":13,"openIssues":13,"contributorsCount":14,"subscribersCount":14,"size":14,"stars1d":13,"stars7d":15,"stars30d":16,"stars90d":14,"forks30d":14,"starsTrendScore":17,"compositeScore":18,"rankGlobal":10,"rankLanguage":10,"license":19,"archived":20,"fork":20,"defaultBranch":21,"hasWiki":22,"hasPages":20,"topics":23,"createdAt":10,"pushedAt":10,"updatedAt":31,"readmeContent":32,"aiSummary":33,"trendingCount":14,"starSnapshotCount":14,"syncStatus":34,"lastSyncTime":35,"discoverSource":36},82015,"blockstor","cozystack\u002Fblockstor","cozystack","Free Software-Defined Storage System based on Kubernetes","https:\u002F\u002Fgithub.com\u002Fcozystack\u002Fblockstor",null,"Go",41,1,0,9,14,3,48.8,"Apache License 2.0",false,"main",true,[5,24,25,26,27,28,29,30],"drbd","kubernetes","linux","lvm","replication","sds","zfs","2026-06-12 04:01:36","![Blockstor](img\u002Fblockstor-logo-black.svg#gh-light-mode-only)\n![Blockstor](img\u002Fblockstor-logo-white.svg#gh-dark-mode-only)\n\n# Blockstor\n\n**Blockstor** is a Kubernetes control plane for LVM and ZFS storage with [DRBD](https:\u002F\u002Flinbit.com\u002Fdrbd\u002F) replication. It speaks a [LINSTOR](https:\u002F\u002Flinbit.com\u002Flinstor\u002F)-compatible REST API, so the clients you already use — `linstor-csi`, `piraeus-operator`, `ha-controller`, `golinstor`, the `linstor` CLI — keep working unchanged.\n\nThe difference is what's underneath. Instead of a central controller with its own database and synchronous RPC to every node, blockstor is built the way Kubernetes operators are built: the desired state lives in CRDs, and a set of `controller-runtime` reconcilers drive the cluster toward it. There is no external database to back up, no in-memory state to lose on restart, and no controller→node polling to fall behind.\n\n## Why?\n\n### Kubernetes-native architecture\n\n- **Reconciliation control plane.** State of truth lives in Kubernetes CRDs; controller and satellite are `controller-runtime` managers with watch-based informers, declarative reconcile loops, and Status SSA. No synchronous fan-out RPC, no central in-memory state, no per-request controller→node polling. Desired\u002Fobserved convergence is automatic.\n- **First-class CRDs.** `Resource`, `ResourceDefinition`, `ResourceGroup`, `StoragePool`, `Snapshot`, `Node`, `PhysicalDevice` are designed to be read and (where appropriate) written by other operators: cozystack tenant operators, GitOps tooling, custom monitoring\u002Falerting, admission webhooks. Schemas carry kubebuilder enum\u002Fmin\u002Fmax validation; multi-writer Status uses Server-Side Apply field managers.\n- **Per-node satellite as a controller.** Each satellite is a controller-runtime manager that watches its own slice of CRDs (filtered by `Spec.NodeName`) and writes observed state back via Status SSA directly. No gRPC dispatch from a central controller.\n\n### Ecosystem fit\n\n- **Built in Go.** Go is the lingua franca of the Kubernetes ecosystem — apiserver, kubelet, etcd, the bulk of CSI drivers, controller-runtime itself — so blockstor shares its tooling, libraries, and contributor base.\n- **Small footprint.** The controller, apiserver, and satellite are statically-linked Go binaries — no JVM and no language runtime to ship — and DRBD is a Linux kernel module rather than a userspace daemon. The images are multi-arch (`linux\u002Famd64`, `linux\u002Farm64`) and cross-compile cleanly, so blockstor fits on edge and small ARM nodes where a multi-hundred-megabyte Java runtime would not.\n\n## Status\n\nWhat works today:\n\n- [x] Replicated volumes over DRBD, on LVM, LVM-thin, ZFS, ZFS-thin, or file backends\n- [x] Running **without DRBD** — plain local storage (single-replica diskful or diskless)\n- [x] **LUKS encryption** — volume-level encryption at rest\n- [x] Autoplacement with constraints (zones, node properties, replicas-on-different)\n- [x] TieBreaker + quorum policies\n- [x] **Snapshots** — create, restore as a new resource, roll back, and clone\n- [x] Intra-cluster snapshot shipping (`zfs send`\u002F`recv`, `thin-send-recv`) for clone \u002F add-replica\n- [x] Online volume resize\n- [x] Device-pool creation from physical disks (`physical-storage create-device-pool`)\n- [x] LINSTOR-compatible REST API for the whole client ecosystem, served over mTLS\n\nNot implemented — the API answers these with `501 Not Implemented`:\n\n- [ ] Cross-cluster snapshot shipping (disaster recovery)\n- [ ] Backup create \u002F restore \u002F ship \u002F abort, and the backup queue\n- [ ] Schedules (cron-driven backups)\n- [ ] Remote backends — S3, LINSTOR remotes\n- [ ] Extra storage providers — SPDK, NVMe-oF, OpenFlex, Exos\n\nOn the roadmap:\n\n- [ ] **Bring-your-own-key encryption** — operator-managed Secret references in the spec, instead of a controller-owned passphrase bag\n- [ ] **Migration tool from LINSTOR** — adopt an existing LINSTOR cluster's resources into blockstor in place\n- [ ] [Shared-LUN provisioning](https:\u002F\u002Fgithub.com\u002FoVirt\u002Fvdsm\u002Fblob\u002Fmaster\u002Fdoc\u002Fthin-provisioning.md) — thick LVM plus thin qcow2-on-LVM, no filesystem layer\n- [ ] [VDUSE backend](https:\u002F\u002Fblog.deckhouse.io\u002Flvm-qcow-csi-driver-shared-san-kubernetes-81455201590e) via `qemu-storage-daemon`, for shared-SAN Kubernetes\n\n## Getting started\n\nBlockstor installs onto an existing cluster and is driven with the standard `linstor` client and piraeus `linstor-csi`. The full walkthrough — installing the control plane, registering nodes and pools, and wiring up CSI — lives in **[`docs\u002Fusage.md`](docs\u002Fusage.md)**.\n\nThe three images are published to GHCR on every release:\n\n- `ghcr.io\u002Fcozystack\u002Fblockstor-controller` — the reconcilers\n- `ghcr.io\u002Fcozystack\u002Fblockstor-apiserver` — the LINSTOR-compatible REST API (mTLS)\n- `ghcr.io\u002Fcozystack\u002Fblockstor-satellite` — the per-node DRBD \u002F storage agent\n\n## Documentation\n\n- [`docs\u002Fusage.md`](docs\u002Fusage.md) — install and operate blockstor with the `linstor` client + piraeus\u002Flinstor-csi.\n- [`docs\u002Farchitecture.md`](docs\u002Farchitecture.md) — the load-bearing design decisions.\n- [`docs\u002Flayer-stack.md`](docs\u002Flayer-stack.md) — DRBD \u002F LUKS \u002F STORAGE compositions.\n- [`AGENTS.md`](AGENTS.md) — repository layout and the local Talos+QEMU dev stand, for contributors.\n\n## Acknowledgements\n\nBlockstor was inspired by LINBIT's [LINSTOR](https:\u002F\u002Flinbit.com\u002Flinstor\u002F), and it operates [DRBD](https:\u002F\u002Flinbit.com\u002Fdrbd\u002F) to provide block-level replication. It deliberately speaks LINSTOR's API so that the rich ecosystem the LINSTOR community has built keeps working unchanged. Heartfelt thanks to LINBIT and to the wider DRBD \u002F LINSTOR \u002F Piraeus community.\n\n## License\n\nBlockstor is licensed under [Apache 2.0](LICENSE). The code is provided as-is with no warranties.\n\nThird-party Go modules and their licenses are catalogued in [THIRD_PARTY_LICENSES.md](THIRD_PARTY_LICENSES.md); the runtime dependency graph is constrained to an Apache-2.0–compatible allowlist (Apache-2.0, BSD-2-Clause, BSD-3-Clause, MIT, MPL-2.0, ISC) by the license-scan CI gate in [`.github\u002Fworkflows\u002Flicense-check.yml`](.github\u002Fworkflows\u002Flicense-check.yml). For interoperability with LINSTOR clients, type definitions are sourced from the Apache-2.0 [`golinstor`](https:\u002F\u002Fgithub.com\u002FLINBIT\u002Fgolinstor) library; blockstor does not copy or generate code from upstream LINSTOR (GPL) sources.\n\n## Trademarks\n\nLINSTOR, LINBIT, and DRBD are trademarks or registered trademarks of LINBIT. Blockstor is an independent project and is not affiliated with, endorsed by, or sponsored by LINBIT.\n","Blockstor 是一个基于 Kubernetes 的开源软件定义存储系统，支持 LVM 和 ZFS 存储，并通过 DRBD 实现数据复制。该项目使用 Go 语言开发，兼容 LINSTOR REST API，能够无缝集成现有的 LINSTOR 客户端工具。Blockstor 采用 Kubernetes 原生架构设计，通过 CRD 和控制器运行时协调器实现状态管理和自动收敛，无需中心化的数据库或同步的节点轮询机制，提升了系统的可靠性和可维护性。此外，它还支持多种存储后端、LUKS 加密、快照等功能，适用于需要高可用性和数据一致性的分布式存储场景，特别适合边缘计算环境及资源受限的小型 ARM 设备部署。",2,"2026-06-11 04:07:28","CREATED_QUERY"]