Why flexBlock

FlexBlock is a userspace Linux block device that keeps its durable copy in object storage and serves I/O through a local NVMe write-back cache. To the kernel it is an ordinary block device, /dev/ublkbN, that can be formatted with a native filesystem, mounted, grown, and moved between hosts. To the storage bill it is a bucket of compressed chunk objects plus a fast local SSD that is used only as a cache.

A volume is defined by what is in the bucket, never by the host that serves it. The device size, block size and compression live in a small superblock object next to the data. Any host with the right license grant and a suitable cache device can attach the volume and start serving it, and the cache warms on demand.

In short: NVMe in the front, object storage in the back.

Advantages

Flexible Sizing

A volume can be far larger than the cache, which holds only what is in use. You pay object-storage prices for capacity and use NVMe for the hot set.

Durability for Ephemeral NVMe

Ephemeral instance drives vanish when the instance stops. As a flexBlock cache they risk only writes not yet flushed, though what remains in the bucket may need a filesystem check.

Host Portability

Only the ownership marker names the host. Detach here, attach there, and the cache warms on demand. The marker and a write lease keep two hosts from writing a volume at once.

Crash-Safe Write-Back

Writes are acknowledged from NVMe, a write-ahead log records intent, and dirty chunks stream to the bucket. A daemon crash recovers with the filesystem still mounted.

Block Compression

Every chunk can be compressed with zstd, lz4 or snappy before upload, and is stored under one key per chunk, overwritten in place.

Total Visibility

Prometheus metrics for cache, write-back lag and storage health. systemd units, XFS and ext4 mounts and NVMe-oF/TCP export are documented with worked examples.

Flexible sizing

The cache can be much smaller than the volume. Its size determines how much of the volume can be hot at once, and how much dirty data can accumulate before writes wait for write-back. A cache that is a meaningful fraction of the working set is what gives local-SSD performance. The device size is bounded by your license grant and can be grown later, up to that bound, but never shrunk.

Durability for ephemeral NVMe

The local NVMe on storage-optimized cloud instances is fast and included in the instance price, but its contents are lost when the instance stops or is replaced. As a flexBlock cache it needs no durability of its own: everything it holds is either already in the bucket or on its way there.

What is at risk when such an instance disappears without a clean stop is only the write-back window: acknowledged writes that had not yet been flushed. By default --flush-threshold holds that window to about four minutes while uploads keep up with writes (eight for a chunk under continuous writes). A replacement instance takes the volume over with attach --take-ownership and serves it from a cold cache; its first start waits 285 seconds so the old owner can no longer write. See Ownership.

Not a point-in-time copy

The bucket is not a point-in-time copy of the volume. Chunks upload one at a time as they age, and a filesystem flush only reaches the cache device, so after an abrupt loss of the cache the bucket holds each chunk as it was last uploaded: recent writes to different chunks may be only partly present. Expect the filesystem to replay its journal or need a repair (xfs_repair, fsck), and verify databases before trusting them. See Where Data Can Be Lost.

Host portability

Apart from the ownership marker, nothing about the serving host is written into the bucket, so moving a volume is a detach on one host and an attach on the other. The new host’s cache can be a different size and kind of device. If uploads from the old host could still land, the first start on the new host waits 285 seconds. See Ownership.

Crash-safe write-back

A write is durable on NVMe before it is acknowledged; the upload to object storage happens later, in the background. If the daemon dies, the kernel holds the block device in place, and running start again recovers it with in-flight requests reissued. See How flexBlock Works.

Block compression

Compression is chosen at init (zstd by default) and can be changed later. Each object records its own compression, so changing the algorithm leaves older objects readable. See Compression and Encryption.

Total visibility

The daemon can serve a Prometheus endpoint with more than a hundred series covering the cache, write-back, object storage, the cache device and the license. See Metrics Endpoint.

Ideal for

• Large databases that outgrow the capacity of local disks.
• Cloud instances whose ephemeral NVMe needs a durable home.
• Block workloads moving to object storage without application changes.
• Remote access: export the device over NVMe-oF/TCP, or share a filesystem on it over NFS, SMB and other protocols.

Works with

Category	Supported
Object storage	Amazon S3 and S3-compatible stores, Google Cloud Storage, Azure Blob Storage, OCI Object Storage
Operating system	Linux 6.1 or newer, x86_64 or aarch64
Filesystems and layers	XFS, ext4, btrfs, OpenZFS, LUKS, LVM, mdadm (close any LUKS, LVM or md mapping on the device before stopping the daemon; it refuses to stop while device-mapper or another kernel user holds the device)
Service management	systemd
Network access	NVMe-oF/TCP export of the device; NFS or SMB shares of a filesystem on it

Next steps

• Performance: how flexBlock compares with the raw NVMe it runs on.
• Requirements: what the serving host, cache device and object store need.
• How flexBlock Works: the architecture in operator terms.