这种情况真的挺闹心的——本来想修复文件系统失衡，结果反而搞挂了系统。咱们一步步来排查和恢复：

第一步：优先尝试只读挂载备份数据 #

首先，先试试把文件系统挂载为只读模式，这能绕过一些因写入导致的损坏问题，先把重要数据捞出来再说：

# 替换/dev/your-btrfs-device为你的实际设备（比如/dev/sda1），/mnt是挂载点
mount -o ro /dev/your-btrfs-device /mnt

如果挂载成功，立刻把关键数据复制到外部存储，这是最优先级的操作。

第二步：检查文件系统损坏情况 #

如果只读挂载失败，用Btrfs自带的检查工具排查问题，先不要直接修复，先做只读扫描：

btrfs check --readonly /dev/your-btrfs-device

这个命令会输出文件系统的结构问题，比如元数据损坏、设备关联异常等，这些信息是后续修复的关键。

第三步：确认loop设备状态 #

你之前添加了3GB的loop设备作为临时空间，平衡后文件系统可能依赖这个设备才能正常运行。先检查设备列表：

# 如果能挂载的话，执行这个
btrfs filesystem show /mnt
# 或者直接针对设备查询
btrfs filesystem show /dev/your-btrfs-device

如果列表里有那个loop设备，先重新关联它：

# 替换/dev/loopX为可用的loop设备号（可以用losetup -f找空闲的），/path/to/3gb-file是你之前dd创建的文件路径
losetup /dev/loopX /path/to/3gb-file
# 然后尝试重新挂载
mount /dev/your-btrfs-device /mnt

要是loop设备的文件已经丢失，那可能需要先通过btrfs-check修复元数据，再尝试移除失效的设备。

第四步：谨慎修复文件系统 #

如果btrfs-check明确指出了可修复的问题，在备份完所有能拿到的数据后，可以尝试修复：

btrfs check --repair /dev/your-btrfs-device

⚠️ 注意：--repair参数可能会删除损坏的元数据或文件，所以一定要先备份，而且只在万不得已的时候用。

后续建议 #

等文件系统恢复正常后：

• 先移除那个临时loop设备：btrfs device remove /dev/loopX /mnt
• 清理文件系统空间（删除大文件、日志等），确保有足够的剩余空间（至少10%以上）
• 重新执行平衡时，用更保守的参数减少空间占用，比如：

  btrfs balance start -dusage=50 -musage=50 /mnt
  

  这个命令只会平衡数据和元数据使用率超过50%的块组，避免占用过多临时空间。

内容的提问来源于stack exchange，提问作者multithr3at3d