On Jul 22, 2014, at 11:24 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Chris Murphy posted on Tue, 22 Jul 2014 20:36:55 -0600 as excerpted: >> >> Used strace on df, think I found the problem so I put it all into a bug. >> >> https://bugzilla.kernel.org/show_bug.cgi?id=80951 > > Suggestion for improved bug summary/title:
So as it turns out this is not a bug, but ultimately a bigger problem. When a btrfs volume is mounted degraded, df's "Available" appears to be showing free blocks in already allocated chunks, multiplied by 2 in the case of raid1. > ** ON BTRFS RAID1, TWO DEVICES MUST BE PRESENT IN ORDERED TO ALLOCATE NEW > CHUNKS. MOUNTING DEGRADED WITH A SINGLE DEVICE MEANS NO NEW CHUNK > ALLOCATION, WHICH MEANS YOU'RE LIMITED TO FILLING UP EXISTING CHUNKS ** I can confirm this behavior (see below). ## mounted degraded, a 13GB btrfs raid1 volume # df -h /dev/sdb 26G 11G 6.1M 100% /mnt/braid # btrfs fi df /mnt/braid Data, RAID1: total=5.00GiB, used=5.00GiB System, RAID1: total=8.00MiB, used=64.00KiB Metadata, RAID1: total=1.00GiB, used=7.00MiB unknown, single: total=64.00MiB, used=0.00 cp a 3.0M file to /mnt/braid cp: error writing ‘/mnt/braid/four/cmurp_120916_124629.jpg’: No space left on device cp: failed to extend ‘/mnt/braid/four/cmurp_120916_124629.jpg’: No space left on device Next steps are: - reconnect missing device and reboot - mount btrfs volume normally - retry the 3MB file copy, which works - umount, disconnect device and reboot - mount -o degraded # df /dev/sdb 26382984 10519488 2077888 84% /mnt/braid # df -h /dev/sdb 26G 11G 2.0G 84% /mnt/braid # btrfs fi df /mnt/braid Data, RAID1: total=6.00GiB, used=5.01GiB System, RAID1: total=8.00MiB, used=64.00KiB Metadata, RAID1: total=1.00GiB, used=7.00MiB unknown, single: total=64.00MiB, used=0.00 Another 1GB chunk has been allocated, and is now possible to write degraded again, up to a GiB of data. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
