Fixing 'Device Busy' on a FreeBSD GEOM Provider Without Forcing Data Loss

FreeBSD GEOM providers form a graph: a disk can contain a partition, which feeds GELI, which feeds a mirror, which holds a filesystem. “Device busy” usually means some consumer still has the provider open or a higher GEOM layer depends on it. The fix is to identify and stop that consumer from the top down, not to erase metadata until the error disappears.

Freeze the intended operation

Stop retrying gpart delete, geli detach, zpool labelclear, or dd. Record the exact command and error, device serial/model, partition table, labels, mounted filesystems, swap, pools, and GEOM tree:

gpart show -p
geom status
geom disk list
mount -p
swapinfo
zpool status

Use /dev/diskid, GPT labels, serials, and size to confirm identity. Kernel enumeration names such as da1 can change after reconnect or reboot.

Find ordinary consumers first

A mounted filesystem holds its provider. Find mount points with mount, df, and fstat; stop services using them, change working directories, and unmount normally. A process whose current directory lies below the mount can keep it busy even after visible application work ends.

Swap providers appear in swapinfo. Disable only the exact target after checking memory headroom:

swapoff /dev/gpt/swap-old

Crash-dump configuration, md devices, jails, bhyve guests, iSCSI, HAST, and ZFS pools can also consume providers. Export a ZFS pool through zpool export rather than pulling its disks out from below it.

Walk GEOM from child to parent

If /dev/ada0p3 backs /dev/ada0p3.eli, detach or stop the consumer of .eli first. If the encrypted provider belongs to a mirror, stop/export the mirror’s consumer before detaching GELI. Each layer’s manual describes its safe stop command and force semantics.

geom eli status
gmirror status
glabel status

geom class commands and kern.geom.debugflags can bypass safety checks, but using them as a generic fix risks writes through stale consumers and metadata destruction. Force is appropriate only when the complete topology is understood, data is backed up, and the documented command’s exact consequence is acceptable.

Distinguish an open provider from stale metadata

GEOM “tastes” providers and may instantiate classes when recognized metadata is present. A device can therefore appear in a mirror or label class even when no filesystem is mounted. First decide whether that metadata represents a real degraded array, an encrypted volume, or an abandoned experiment.

Use class-specific inspection to save metadata and identify every component. Clear metadata only after confirming the object should be destroyed and no recovery is needed. Wiping the first and last megabytes is not a diagnostic technique; it can erase partition tables, bootcode, filesystem superblocks, and multiple GEOM labels at once.

Removable media adds detach races

USB storage may disappear while buffers or GEOM classes still reference it. Capture kernel messages and hardware errors. Do not repeatedly reconnect a failing disk read-write; image it through a recovery-oriented tool when data matters. A transport reset can look like a software busy problem while the real issue is media or enclosure failure.

When the goal is safe physical removal, unmount filesystems, disable swap, export pools, stop GEOM classes, flush writes with the supported tools, then detach/eject. Verify the provider no longer appears as an active consumer before unplugging.

Prove the intended postcondition

After teardown, rerun the inventory. Confirm no mount, swap, pool, jail, VM, process, or GEOM child references the provider. Only then perform the partition or metadata operation. If repurposing the disk, create a new partition table and filesystem from a reviewed plan, then verify labels and mount targets before adding boot-time configuration.

The busy check is a storage safety barrier. Treat it as evidence of an unresolved dependency and remove that dependency cleanly; disabling the barrier is not the same as resolving it.

Related:

Sources: