Dennis HilkLinux Fix LabDE

Storage & Filesystems

Btrfs ENOSPC despite apparent free space

Check Btrfs data and metadata allocation separately when snapshots or writes fail with ENOSPC although a simple free-space report looks sufficient.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • Snapshot creation or metadata changes fail with No space left on device.
  • df free space does not explain the allocation failure.

Relevant environment

Btrfs single-device or multi-device filesystems with copy-on-write allocation and snapshots.

Recognizable messages (synthetic examples)
BTRFS: error (device sda2) in btrfs_commit_transaction: errno=-28 No space left

Inspect metadata and per-device allocation; a generic application ENOSPC cannot establish this specific mechanism.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • Metadata chunks, per-device unallocated space or a profile constraint may prevent new allocations despite spare space inside data chunks.
  • Snapshots retain referenced extents; deleting a visible file may not release its underlying storage immediately.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Replace /mountpoint with this Btrfs mount. Read allocation and per-device usage; administrator access may be needed.

sudo btrfs filesystem usage -T /mountpoint

Interpret the result: Compare Metadata used/total and Device unallocated, including the active profile. Aggregate free estimates are not a promise that the next metadata allocation can succeed.

Check 2

Read subvolume and snapshot paths for the chosen mount; this does not delete them.

sudo btrfs subvolume list /mountpoint

Interpret the result: Many snapshots identify retained history to review, not automatic deletion candidates. Snapshots can share extents, so their sizes cannot simply be added.

Evidence-guided next steps

Review retained data and snapshots

If unused snapshots retain old data, review retention with the backup or snapshot tool and remove only snapshots confirmed unnecessary after verifying independent backups. Allow delayed cleanup to finish before reassessing usage.

Precautions: A snapshot on the same filesystem is not an independent backup. Deletion loses that recovery point and may still require metadata space.

Recovery / rollback: Deleted snapshots cannot be undeleted reliably; restore required history from the independent backup.

Did this solution help you?

Share this solution#

Consider a narrowly filtered balance

If usage shows empty allocated chunks but inadequate unallocated space, consider an empty-chunk balance with usage=0 filters for data and metadata after reviewing the upstream procedure. It reclaims empty block groups without relocating live extents.

Precautions: Do not launch an unfiltered balance on an almost-full filesystem; relocation needs workspace. Profile changes and adding devices need a separate recovery plan.

Recovery / rollback: A balance reorganizes allocation and is not an undo operation. Keep backups; cancel a longer relocation if unexpected failures occur and reassess device health.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.