BTrFS 崩潰了？
我使用兩個 250GB 驅動器和第三個 80GB 驅動器上的第二個分區創建了一個新的 BTrFS raid10 文件系統。我創建了一個 subvol 和快照。我掛載快照並開始向其中複製 8GB 數據。它達到 1GB 左右，桌面消失，看起來像非互動式終端的東西出現了轉儲/崩潰資訊。我手邊沒有相機，否則我會拍照並發布。它基本上看起來像堆棧跟踪資訊。CTRL-ALT F7 最終將帶回桌面，但作業系統的整個 BTrFS 部分都掛起並且沒有響應，直到我重新啟動。
我現在已經重新格式化並重現了這個問題 3 次，我即將放棄:(
我意識到這個問題可能並不完全是 BTrFS 的錯，因為我在 natty 上仍然是 alpha。
如果我是白痴，請提供更詳細的細節：
1) Create FS: sudo mkfs.btrfs -m raid10 -d raid10 /dev/sda2 /dev/sdb /dev/sdc 2) Initial temporary mount: mkdir /btrfs && sudo mount -t btrfs /dev/sda2 /btrfs 3) Create subvol btrfs s c /btrfs/vm 4) Create initial snapshot: (optional) btrfs s sn /btrfs/cantremember.snap.something 5)unmount /btrfs and mount /btrfs/vm sudo mount -t btrfs -o subvol=vm /dev/sda2 /btrfs/vm 6) Copy data to subvolume. 7) Balance data across drives: (optional) btrfs f bal <path>（永遠不要進入這一步 7 ……）我做錯了什麼嗎？
編輯：我設法抓住了回溯/崩潰資訊的結尾：
/build/buildd/linux-2.6.38/fs/btrfs/extent-tree.c:8581 處的核心 BUG
EDIT2：從 raid10 陣列中刪除最小的（46GB）分區似乎已經消除了這個問題。
從它的聲音來看，你遇到了這個：
分配是在循環的基礎上完成的。如果您在由不匹配的驅動器（不同大小的捲）組成的捲上使用 raid1 策略，則較小的捲可能會被填滿，同時在單個最大驅動器上留下大量可用空間。如果“df”和“btrfs 文件系統 df”之間存在任何差異，您可以驗證這是一個問題
$$ mountpoint $$’ 並且如果後一個命令還顯示“數據”行上的“總計”和“已使用”相同。再平衡可能會緩解這個問題。(2.6.33)
- 如果您的音量確實以這種方式填滿，重新平衡可能會很快導致 ENOSPC（“錯誤 NO SPaCe 留在設備上”）哎呀。您可能必須刪除一個相對較大的文件來解決這個僵局，然後再平衡就會成功。(2.6.33)
https://btrfs.wiki.kernel.org/index.php/Gotchas
強調我的。你提到的第三個 80GB 驅動器上的第二個分區可能在這對 250GB 驅動器之前就已經填滿了，它觸發了這個特殊的問題。
此外，出於某種原因，BTrFS 是一個 beta 文件系統。