Skip to content
flexFS

Billing Model

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

Cost per file

Section titled “Cost per file”

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 used, 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

Section titled “How the activity tier is determined”

Each file’s rate comes from its size bin — an activity tier, numbered 0 through 127, 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 127. 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 I/O on a file’s data warms it — opening it for reading, reading, writing, truncating, or extending it. Metadata-only operations do not: listing a directory, running stat, chmod, 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.
  • Older mounts are counted from their requests. Mounts normally report data I/O to the metadata server directly. For a mount that does not report activity, the server counts the requests its I/O produces instead: the access-time update on a read-open, and the block and size updates on a write or truncate. Such a mount’s reads are visible only on open, so a file it holds open for a long time is not recognized as warm; mounting it with noatime hides its reads entirely. A file whose data has not been used since activity recording began is placed by the most recent of its access, modification, and creation times.
  • Timestamps set by hand do not move the tier. Backdating a file’s access or modification time will not move it to a cheaper tier, a bare touch will not warm it, and a file is never placed colder than its creation time. 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.

Next steps

Section titled “Next steps”