One Block Device, Many Jobs
Wherever a workload needs a fast local disk but the data deserves the durability, capacity and economics of object storage, flexBlock fits underneath without changing a line of code.
Room to grow, at local-disk speed
Production databases outgrow the local disks they run fastest on. FlexBlock gives PostgreSQL, MariaDB and other databases a volume far larger than the drive, with the hot pages, journal and log on NVMe and everything else in the bucket. Writes to chunks already waiting for upload are never held back by write-back pacing, so a database's hot pages, journal and log keep their latency.
Compatible with: PostgreSQL, MariaDB, MySQL, and any database that runs on XFS or ext4
Key Benefits
- MariaDB write-only OLTP ran at 117% of raw NVMe; PostgreSQL select-only at 98%
- Grow the volume as the database grows, live on Linux 6.16 or newer, then grow the filesystem online
- Commits survive a daemon crash: acknowledged writes are on NVMe, and a write-ahead log tracks what is still to upload
- Checked with pg_amcheck and CHECK TABLE EXTENDED after reopening cold from the bucket
Make instance-local NVMe safe to use
Storage-optimized cloud instances come with fast local NVMe that is included in the price but lost when the instance stops. Used as a flexBlock cache, that drive needs no durability of its own: everything on it is already in the bucket or on its way there.
Compatible with: AWS, Google Cloud, Azure and Oracle Cloud instances with local NVMe
Key Benefits
- Use the fastest, already-paid-for storage on the instance for real data
- An abrupt instance loss costs the writes not yet flushed, about four minutes' worth by default, and the filesystem may need a check, since the bucket is not a point-in-time copy
- A replacement instance takes the volume over and warms its cache on demand
- No data is bulk-copied when a new instance attaches
Object storage capacity, NVMe performance
Many large volumes have a small hot set: the recent partitions, the active projects, today’s logs. FlexBlock keeps that working set on NVMe and the rest as compressed objects in your bucket, so you size the cache for what is in use, not for everything you keep.
Compatible with: Archives, analytics stores, home directories, build and artifact caches
Key Benefits
- A volume can be far larger than its cache device
- Data can be compressed with zstd (the default), lz4 or snappy before it reaches the bucket
- Cold data comes back on first touch, with prefetch for sequential scans
- Grow the volume later, up to your licensed size, without migrating anything
Move block workloads to object storage unchanged
Applications written for a local disk don’t need to learn object storage APIs. FlexBlock presents the bucket as an ordinary Linux block device, so existing software, filesystems and tools keep working as before while the data lands in object storage.
Compatible with: Any Linux software that reads and writes a disk
Key Benefits
- A standard /dev/ublkbN device on Linux 6.1 or newer that works with XFS, ext4, btrfs, OpenZFS, LUKS, LVM and mdadm
- No application, driver or SDK changes
- Works with Amazon S3, S3-compatible stores with conditional writes, Google Cloud Storage, Azure Blob Storage and OCI Object Storage
- Runs under systemd, with documented units for mounts and exports
Volumes that are not tied to a machine
Nothing about the serving host is stored with the volume except who owns it. Detach a volume from one machine and attach it to another, even one with different hardware, and the new cache warms as the volume is used.
Compatible with: Instance replacements, hardware refreshes, failover runbooks
Key Benefits
- Move volumes between hosts for maintenance, upgrades or rebalancing
- Take a volume over from an unreachable host, with a built-in wait that lets the old owner stop writing first
- Ownership checks keep two hosts from writing the same volume at once
- The volume’s data never leaves the bucket during a move
Serve the volume to other machines
A flexBlock device is an ordinary block device, so the standard Linux servers can share it. Export it as an NVMe namespace over TCP with the kernel’s own target, or put a filesystem on it and share that over NFS or SMB.
Compatible with: nvmet and nvme-cli, NFS, Samba
Key Benefits
- Documented NVMe-oF/TCP export with systemd units for target and initiator
- With the documented reconnect settings, initiators see a stall, not errors, if the serving daemon restarts
- Combine NVMe-speed local caching with object storage capacity behind a network share
- Use the access controls of the export protocol you already run
Have a Workload in Mind?
Follow Your First Volume in the docs, or tell us about your volumes and we will help you plan the deployment.