Many sysadmins encounter this frustrating scenario: you create a BTRFS filesystem on raw devices instead of partitions, then realize your mistake and recreate it properly - but the original volume stubbornly remains in the system's memory. Even after multiple removal attempts with btrfs device delete and reformatting, the phantom volume persists in btrfs fi show output.

The core issue lies in how BTRFS maintains metadata. When you create a filesystem on raw block devices (like /dev/sda instead of /dev/sda1), BTRFS writes its superblock directly to the device. Subsequent operations on partitions don't automatically clear this metadata.

# Common failed removal attempt:
sudo btrfs device delete /dev/sda /mnt/point
# Returns "Inappropriate ioctl for device" because:
# 1. The device isn't properly mounted
# 2. The filesystem metadata remains persistent

Here's the definitive method I've used to completely wipe BTRFS configurations:

# First, unmount all BTRFS filesystems
sudo umount /media/flashdrive

# Wipe filesystem signatures using wipefs (most thorough method)
sudo wipefs -a /dev/sda
sudo wipefs -a /dev/sdb

# For stubborn cases, use dd to zero superblocks
sudo dd if=/dev/zero of=/dev/sda bs=1M count=256
sudo dd if=/dev/zero of=/dev/sdb bs=1M count=256

# Recreate partition tables (example with fdisk)
echo -e "o\nn\np\n1\n\n\nt\n83\nw" | sudo fdisk /dev/sda
echo -e "o\nn\np\n1\n\n\nt\n83\nw" | sudo fdisk /dev/sdb

# Verify removal
sudo btrfs fi show
# Should show no filesystems if successful

After complete removal, create your new pool properly:

# Using partitions this time
sudo mkfs.btrfs -d single -L "flashpool" /dev/sda1 /dev/sdb1

# Mount with modern options for better performance
sudo mount -o noatime,compress=zstd:3,ssd,discard=async /dev/sda1 /media/flashdrive

Some best practices I've learned:

• Always use partitions (e.g., /dev/sdX1) for BTRFS, not raw devices
• Consider using wipefs as part of your standard cleanup procedure
• For production systems, use blkid to verify device signatures before operations

When working with BTRFS filesystems, sometimes old configurations stick around even after reformatting devices. This typically happens when:

• Creating filesystems directly on raw disks instead of partitions
• Changing RAID profiles or device configurations
• Kernel metadata caching issues

From your btrfs fi show output, we can see two distinct filesystems:

# Current working filesystem (partition-based)
UUID: ba0b48ce-c729-4793-bd99-90764888851f
Devices: /dev/sda1, /dev/sdb1

# Stale filesystem (raw disk-based)  
UUID: 17020004-8832-42fe-8243-c145879a3d6a
Devices: /dev/sda, /dev/sdb

The proper way to completely clean this up involves several steps:

Step 1: Unmount all BTRFS filesystems

sudo umount /media/flashdrive
sudo umount /dev/sda
sudo umount /dev/sdb

Step 2: Wipe filesystem signatures

sudo wipefs -a /dev/sda
sudo wipefs -a /dev/sdb
sudo wipefs -a /dev/sda1
sudo wipefs -a /dev/sdb1

Step 3: Clear BTRFS device scanning

sudo btrfs filesystem show | grep uuid
# For each unwanted UUID:
sudo btrfs device scan --forget /dev/sda
sudo btrfs device scan --forget /dev/sdb

Step 4: Recreate partition tables

sudo fdisk /dev/sda
# Press g to create new GPT table, then n to create new partition
# Repeat for /dev/sdb

After completing these steps, verify with:

sudo btrfs fi show
sudo blkid
sudo lsblk -f

If the above doesn't work, try destroying all BTRFS metadata:

sudo dd if=/dev/zero of=/dev/sda bs=1M count=256
sudo dd if=/dev/zero of=/dev/sdb bs=1M count=256
sudo blockdev --flushbufs /dev/sda
sudo blockdev --flushbufs /dev/sdb

Some best practices:

• Always use partitions (/dev/sdX1) not raw disks
• Consider using wipefs before mkfs.btrfs
• Check for existing signatures with blkid first