Capacity Planning

This guide helps you estimate storage requirements, configure quotas, and understand the flexFS billing model for capacity planning.

Storage components

FlexFS storage usage has three components:

Component	Where stored	Sizing factors
Block data	Cloud object storage	Total file data size (after compression). Directly proportional to the data written.
Metadata	Metadata server local disk	Proportional to the number of files, directories, and their attributes.
Cache	Mount client / proxy local disk	Configurable via `--diskQuota`. Working set dependent.

Block data estimates

Block data is the dominant storage cost. After compression, the actual storage used depends on the data type:

Data type	Typical compression ratio (LZ4)	1 TB raw data stored as
Text / source code	3-5x	200-330 GB
Genomics (BAM)	1.1-1.3x	770 GB - 910 GB
Compressed files (gzip, zstd)	1.0x (no benefit)	~1 TB
Binary / random data	1.0x	~1 TB
Parquet / columnar data	1.5-2x	500 GB - 670 GB

Retired blocks

When files are deleted or modified, old blocks are retired but may be retained for time-travel access during the retention period. Factor this into your storage estimates:

Total block storage = active blocks + retired blocks (within retention window)

Monitor retired blocks via the flexfs_meta_volume_blocks_retired metric.

Metadata estimates

Metadata storage scales with the number of filesystem objects, not with file data size.

Filesystem objects	Approximate metadata size
1 million files	1-2 GB
10 million files	10-20 GB
100 million files	100-200 GB
1 billion files	1-2 TB

Factors that increase metadata size per file:

Extended ACLs
Extended attributes
Long file names
Deep directory nesting (more directory entries)
Time-travel retention (historical versions of metadata)

Metadata server disk sizing

Provision metadata server disk space at 2-3x the estimated metadata size to allow for:

Database compaction overhead
WAL (write-ahead log) files
Growth headroom

Monitor disk usage with the flexfs_meta_db_disk_usage_bytes and flexfs_meta_db_folder_disk_capacity_bytes metrics, and headroom with flexfs_meta_db_folder_disk_available_bytes.

Do not plan to run the partition to the last byte: the metadata server refuses to start, and gracefully shuts itself down while running, once available space on the database folder filesystem falls below a configurable minimum (1 GiB by default). Compaction and the flush performed when the database is closed both write into that same folder, so the floor exists to keep a clean shutdown possible; raise it if a deployment needs more headroom. The proxy server guards its own database folder the same way.

Cache sizing

Mount client disk cache

The disk cache holds recently accessed blocks on local disk. Size it based on your working set:

Working set	Recommended `--diskQuota`
Small (< 10 GB active data)	20-50 GB
Medium (10-100 GB active data)	100-500 GB
Large (> 100 GB active data)	500 GB - 1 TB+

Use NVMe SSDs for the cache folder when low latency is important.

Proxy cache

Proxy server caches are shared across all mount clients in the proxy group. Size them based on the combined working set of all clients:

Proxy cache size >= working set of all clients / number of proxy servers

Volume quotas

Enterprise volumes support quotas to limit resource usage:

Quota type	Description
`maxBlocks`	Maximum number of active blocks. Limits total data volume.
`maxInodes`	Maximum number of inodes (files + directories). Limits total file count.

Quotas are set during volume creation or update via configure.flexfs. When maxBlocks or maxInodes is reached, write operations that would exceed the limit fail.

maxProxied is often listed alongside these but is not a quota: it sets how many blocks of each file are served through the proxy group. Blocks at index maxProxied and beyond go direct to object storage, and 0 means every block of every file is proxied. It shapes proxy cache usage and never causes a write to fail.

Monitor quota usage via the flexfs_meta_volume_blocks, flexfs_meta_volume_inodes, and flexfs_meta_volume_size_bytes metrics.

Billing model

Enterprise flexFS usage is metered on a GiB-month basis with activity-based tiered pricing:

Each file’s monthly cost is:

cost = (effective_size / 1 GiB) * rate

Where:

effective_size is the smaller of the file’s logical size and its allocated block size (blksize * blocks), so sparse files are charged only for allocated storage.
rate is a per-GiB monthly dollar amount ($/GiB/month) set by a tiered rate that depends on how recently the file’s data was accessed, so cold data can cost less than hot data. See the Size Bin glossary entry.

The total volume cost is the sum of per-file costs.

Key points:

Billing is based on the logical storage size of individual files, not the compressed size on the backend.
Sparse files are charged based on allocated blocks, not the full logical size.
Files with multiple hard links are counted only once.
Proxy cache and mount client cache do not count toward billed storage.
Use analyze.flexfs and find.flexfs to inspect per-file, per-folder, and per-user costs. See cost field details.

How the activity tier is determined

Each file’s rate comes from its size bin — an activity tier, numbered 0 through 74, that reflects how recently the file’s data was last used. Bin 0 is the hottest tier (data active within the last 30 days); each higher bin is another ~30-day step of inactivity, up to bin 74. A file cools by one tier for roughly every 30 days its data goes untouched, and warms back toward bin 0 when its data is used again. This lets an account charge a lower $/GiB/month rate for cold data than for hot data. (Despite the name, a size bin measures age of last activity, not file size.)

What counts as activity is deliberately narrow, so the tier tracks real working-set usage rather than incidental scans:

Only genuine data I/O warms a file — actually reading or writing its contents. Metadata-only operations do not: listing a directory, running stat, or touching a file leaves its tier unchanged. Reads and writes are treated the same way.
A file warms only when its use is sustained. A single sweep over the data — a backup, a virus scan, an indexing job that opens each file once — does not reprice it. A file moves to a warmer tier only after its data is used repeatedly over time, so a one-time pass will not warm an entire volume.
Access time is the fallback signal. Mounts normally report data I/O to the metadata server directly. A mount that does not report activity (and a file that has never been read) falls back to the file’s access time (atime) to place it in a tier. On that fallback path, mounting with noatime stops reads from refreshing atime, so an actively-used file is not recognized as warm — it drifts toward colder, cheaper tiers as though it were idle.
The tier can only count forward. Backdating a file’s access time will not move it to a cheaper tier; timestamps set into the future are ignored for billing as well.

You can review the current tier of individual files with find.flexfs --fields path,size,size_bin,cost or analyze.flexfs files --friendly, and target stale data for archival or deletion with find.flexfs --minSizeBin / --maxAtime. See Size Bin and Rate Bin.

Planning checklist

Question	How to answer
How much data will I store?	Estimate total file sizes, apply compression ratio.
How many files will I have?	Count files and directories for metadata sizing.
What is my working set?	Identify the subset of data accessed frequently for cache sizing.
How long do I need time-travel?	Set retention period; longer retention = more metadata and retired block storage.
What are my write patterns?	High write rates benefit from a larger disk cache (`--diskQuota`) and, in Enterprise deployments, a proxy group placed near the clients.

Next steps

Performance tuning — optimize caches and block size
Backup and recovery
Metrics reference — monitor usage metrics