Synology Btrfs metadata capacity

Btrfs metadata exhaustion can make a Synology volume fail even when raw capacity still appears available.

Btrfs separates data and metadata allocation. Snapshots, small files, churn, and copy-on-write updates can consume metadata space differently from ordinary capacity, leaving DSM unable to complete transactions or mount the volume normally.

Understand the symptom

Free bytes do not guarantee free metadata chunks or a consistent transaction tree.

WHY

What is happening

Btrfs tracks extents, checksums, directories, roots, and snapshots in metadata trees. A filesystem can have apparent data space while lacking usable metadata allocation or while a tree block is unreadable. Recovery evaluates RAID health, chunk allocation, transaction generations, and snapshot roots before attempting mutation.

What you may see

Symptoms that change the recovery path.

01

Volume crashes with free capacity shown

Overall storage remains, but metadata allocation or tree consistency prevents writes.

02

Snapshot or package tasks fail

Operations cannot reserve or update required metadata.

03

DSM reports Btrfs errors

Transaction, tree-block, or allocation failures appear in logs.

04

Shares become read-only or disappear

Mount protection or failed transaction replay blocks normal access.

Protect the source

Actions that can make the situation worse.

01

Balance rewrites allocation

Chunk relocation adds heavy reads and writes to a filesystem already short on metadata.

02

Snapshot deletion needs metadata

Cleanup can fail while changing the very trees needed for recovery.

03

Package restarts consume the last space

Databases and indexes may generate rapid copy-on-write updates.

Do this now

Safe steps before evaluation.

01

Stop all nonessential services

Pause snapshots, backup, sync, indexing, packages, containers, VMs, and client writes.

02

Capture storage evidence

Save pool and volume status, allocation details, logs, snapshots, disk health, and recent changes.

03

Preserve drives and chassis

Record bay order and keep every current, removed, spare, and replacement disk.

04

Avoid broad repair commands

Do not balance, check with repair, recreate, or delete snapshots before protected copies exist.

NEPFOSYS process

How a data-first evaluation proceeds.

01

Capacity and tree analysis

NEPFOSYS reviews member health, RAID state, Btrfs chunks, roots, and transaction generations.

02

Protected acquisition

Storage members are preserved before metadata-changing operations.

03

Subvolume and file recovery

Reachable trees, snapshots, and priority shares are reconstructed from the most consistent state.

A clear next step

Preserve the original device before another repair or recovery attempt.

Start a case with the exact symptoms, incident timeline, prior attempts, encryption details, and the files that matter most. NEPFOSYS will route the case to the appropriate DFW intake or nationwide mail-in path.

Start with a case review

Questions, answered

What customers ask before starting.

Why is metadata full when the volume has free space?

Btrfs allocates data and metadata in separate chunks; one class can become constrained before total capacity is exhausted.

Will deleting snapshots immediately free space?

It also requires metadata transactions and can worsen an unstable state. Protect the source first.

Is balance a recovery tool?

Balance is a filesystem maintenance operation, not a preservation step, and it rewrites substantial allocation data.

DFW local · Nationwide mail-in

Protect the device. Start with the facts.

Start my recovery case