Skip to content

FAQ

Yes, far larger. The cache holds only the chunks in use, so you pay object storage prices for capacity and NVMe for the hot set. The cache size determines how much of the volume can be hot at once, and how much dirty data can build up before writes wait for uploads. See Volumes and the Cache.

The minimum is one chunk plus about 332 KiB of metadata, but a cache that is a meaningful fraction of your working set is what gives local-SSD performance. Watch the hit rate (flexblock_cache_hits_total against flexblock_cache_misses_total) to judge whether it is big enough. A larger cache also uses more daemon memory; see Memory.

You can grow it, up to the size your license grant covers, and on Linux 6.16 or newer you can do it while the filesystem is mounted. Growing is one-way: volumes cannot shrink. See Growing a Volume.

Can I change the chunk size or block size later?

Section titled “Can I change the chunk size or block size later?”

No. Both are chosen at init and fixed for the volume’s life. Compression and S3 server-side encryption, by contrast, can be changed later with update. See Choosing a Chunk Size.

What happens if the instance’s NVMe drive is lost?

Section titled “What happens if the instance’s NVMe drive is lost?”

Only the write-back window is at risk: writes that were acknowledged but not yet uploaded. With the defaults that is about four minutes of writes while uploads keep up, and flexblock_cache_oldest_dirty_age_seconds tells you the current figure. Everything else is already in the bucket, though not as a point-in-time copy: chunks upload one at a time, so expect a journal replay or a filesystem check (xfs_repair, fsck) and verify databases. A replacement instance attaches the same volume, with attach --take-ownership if the old host could not detach, and serves it from a cold cache. See Where Data Can Be Lost.

What happens if the flexBlock daemon crashes?

Section titled “What happens if the flexBlock daemon crashes?”

The kernel keeps the block device in place and holds its I/O, so a mounted filesystem blocks rather than failing. Run flexblock start on the same cache device; it replays the write-ahead log, recovers the device and the blocked I/O carries on. Under the supplied systemd unit this restart is automatic. Do not reboot first. See Recovering From a Crash.

Watch flexblock_cache_oldest_dirty_age_seconds. Sustained values above twice --flush-threshold (8 minutes by default) mean uploads are not keeping up or are failing. See Alerting.

No. One host owns a volume at a time. Ownership is recorded in a marker object in the bucket, written with conditional writes so two hosts cannot both claim it, and a write lease keeps a previous owner from writing once another host has taken over. To give other hosts access, share it from the owning host, for example over NVMe-oF/TCP; see NVMe-oF/TCP Export. See Ownership.

Stop the daemon cleanly and detach on the old host, then attach and start on the new one with the same grant and credentials. Nothing is bulk-copied; the new cache starts empty and warms on demand, and it can be a different size and kind of device. If the old host is gone, use attach --take-ownership. See Moving a Volume.

Yes, by sharing a filesystem mounted on the device. FlexBlock presents an ordinary block device, so you can format it, mount it on the serving host and share that filesystem with NFS, SMB or other remote-access protocols. You can also export the block device itself over NVMe-oF/TCP; see NVMe-oF/TCP Export. Do not mount the device locally while it is exported over NVMe-oF.

XFS and ext4 have worked examples in this guide; see XFS Filesystem and ext4 Filesystem. btrfs, OpenZFS and LUKS work on the device as on any other block device, as do LVM and mdadm. Close any LUKS, LVM or md mapping on the device before stopping the daemon, because it refuses to stop while device-mapper or another kernel user holds the device. See Filesystem Settings for the settings that matter.

Linux 6.1 or newer, with the ublk_drv module and io_uring enabled, on x86_64 or aarch64. Newer kernels add optional features, detected at start:

KernelAdds
6.15Idle queue threads no longer show as iowait
6.16Zero-copy I/O and online volume growth

See Requirements.

Amazon S3, Google Cloud Storage, Azure Blob Storage and Oracle Cloud Infrastructure Object Storage. Any S3-compatible store works if it enforces conditional PUTs (If-None-Match and If-Match); init and attach check this and refuse a store that does not. See Amazon S3 and the other storage backend pages.

In practice, yes. start and reap drive the kernel’s ublk control device and need root, and attach, detach, update and wipe need write access to the cache device. show needs only read access, and init without --attach touches no device.

Nothing at first. Daily log notices start seven days before expiry, and after expiry the grant’s grace period (if it has one) runs with warnings only. Past the grace period, guest reads and writes are throttled, by default to 64 MiB/s read and 16 MiB/s write, so data can still be evacuated. Flushing to object storage is never throttled. Installing a renewed grant restores full speed within a minute, without a restart. See Licensing, or contact info@paradigm4.com.

Can I make the volume bigger than my license?

Section titled “Can I make the volume bigger than my license?”

No. init and update --device-size cap the device at the licensed size. A device larger than its grant covers is throttled like an expired license.