Can You Mix SATA and NVMe Devices in the Same Btrfs Filesystem?

Yes, Btrfs can use both, but allocation follows profile and available space—not a guaranteed fast tier—so performance and failure behavior become uneven.

The decision matters when a home NAS owner wants to add NVMe capacity to an existing SATA Btrfs filesystem. The two competing states are supported mixed device pool and not automatic caching or tiering. Begin with a saved configuration and disposable data, observe one branch at a time, and stop if the test expands data-loss, permission, or availability risk.

Define the Conditions Behind the Mixed-Device Btrfs Filesystem Decision

Record the environment before changing anything: software and firmware versions, device identities, mount or network path, free space, permissions, and the observable symptom. The baseline must preserve enough detail to reproduce a home NAS owner wants to add NVMe capacity to an existing SATA Btrfs filesystem.

The first candidate is supported mixed device pool. The second is not automatic caching or tiering. The current Btrfs multi-device management defines the mechanism or command boundary used in the test; it does not replace observation from this specific home server.

Write the acceptance condition and stop condition before running the discriminator. A pass must change the evidence predicted by one branch while leaving unrelated services unchanged; a fail must return the system to the saved state rather than trigger a chain of speculative fixes.

Test the Claim Without Lowering the Original Requirement

Use this discriminator: create a disposable mixed pool, inspect chunk allocation, fill it past one device class, and test degraded and replace behavior. Keep workload, client, path, file set, and timing constant so the result is attributable to the changed variable.

Use kernel Btrfs behavior to select the field that can actually separate the branches, then capture its timestamp, exit status, error text, device or snapshot identity, latency, transferred bytes, permissions, and recovery state. A clean command exit is not enough when identity, durability, or application state is the claim under test.

Repeat the test once after a restart, reconnect, remount, or cold cache when that event is part of the original condition. If the first run is destructive or the environment cannot be restored, stop and reproduce on a disposable copy instead.

btrfs filesystem usage /mnt/pool
btrfs balance start -dconvert=raid1 -mconvert=raid1 /mnt/pool

Interpret Pass, Fail, and Exception Results

PASS: data and metadata profiles remain satisfiable and measured performance matches the workload objective. Record the exact version, identity, and workload that passed so the conclusion stays conditional rather than becoming a universal claim.

FAIL: the smallest or slowest device constrains a mirrored profile, or hot data does not stay on NVMe. A fail does not automatically prove the opposite branch when network, memory, permissions, or source consistency can influence both; isolate those shared dependencies before escalating.

EXCEPTION OR AMBIGUOUS RESULT: keep NVMe as a separate filesystem or cache layer when predictable tiering is required. Preserve logs and do not run repair, prune, destroy, repartition, or recursive ownership commands until a recoverable copy exists.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Confirm the Decision Under the Original Workload

Apply the action matched to the observed branch, then repeat the original condition rather than a reduced substitute. The decision holds only when data and metadata profiles remain satisfiable and measured performance matches the workload objective across two cycles or the relevant reboot, sleep, interruption, or load transition.

Use the separate data jobs to check the nearest dependent workflow, but keep the original trigger unchanged. Unrelated datasets, shares, containers, users, and recovery points must retain their previous access and timing.

The stop boundary is explicit: if the smallest or slowest device constrains a mirrored profile, or hot data does not stay on NVMe, return to the last verified configuration, retain the evidence, and escalate to a deeper platform or hardware test only when the branch is repeatable.

After the target result holds, compare it with the post-change verification so the fix does not move risk into a neighboring service. A successful target test with a new backup, identity, timeout, or availability failure is still a failed change.

FAQ

For mixed-device Btrfs filesystem, the remaining searches usually concern will btrfs automatically keep metadata on nvme, does raid1 require equal device sizes, and can nvme be removed later. The answers below keep those edge cases separate from the primary decision.

The acceptance boundary does not move: data and metadata profiles remain satisfiable and measured performance matches the workload objective. If a follow-up condition changes the filesystem, identity, network path, or application version, repeat only the discriminator affected by that change.

Stop broadening the experiment when the smallest or slowest device constrains a mirrored profile, or hot data does not stay on NVMe. At that point, keep NVMe as a separate filesystem or cache layer when predictable tiering is required; preserve the evidence before escalating to the platform, storage, or hardware owner.

Will Btrfs automatically keep metadata on NVMe?

Not simply because a device is faster. Allocation profiles do not create an automatic performance tier.

Does RAID1 require equal device sizes?

No, but usable space and chunk placement depend on device sizes and profile constraints.

Can NVMe be removed later?

Yes when remaining devices can satisfy allocations; run a device remove plan and keep backups.

For mixed-device Btrfs filesystem, the practical answer remains conditional: data and metadata profiles remain satisfiable and measured performance matches the workload objective. When the smallest or slowest device constrains a mirrored profile, or hot data does not stay on NVMe, keep NVMe as a separate filesystem or cache layer when predictable tiering is required; a partial success that cannot survive the original workload is not compatibility.