After a full balance that is likely to change to 4.41TiB used of 4.41TiB total. Is that going to help anything, Peter is saying it's a known bug that convert can't do anything currently.
On Tue, May 26, 2015 at 2:36 AM, Anthony Plack <t...@plack.net> wrote: > >> On May 24, 2015, at 11:00 PM, Gareth Pye <gar...@cerberos.id.au> wrote: >> >> 2. >> 18% or 1.1T spare currently. That isn't what I'd call tiny free space. >> -- >> > > # btrfs fi df /data > Data, RAID1: total=4.43TiB, used=4.41TiB > > Of 4.43TiB, btrfs believes you have used 4.41TiB. > > Chris’s fix to this has to deal with the ENOSPC error "No space left on > device”, not because you don’ t have free space but because your extents are > marked as used and you need a balance operation to clean it up. > > https://patchwork.kernel.org/patch/6238111/ >> Before the reverted commit, this test case failed with ENOSPC because >> all chunks on the freshly converted filesystem were allocated, although >> many were empty. The reverted commit removed an allocation attempt in >> btrfs_set_block_group_ro(), but that fix wasn't right. After the >> reverted commit, the balance succeeds, but the data/metadata profiles >> aren't actually updated: > -- Gareth Pye Level 2 MTG Judge, Melbourne, Australia "Dear God, I would like to file a bug report" -- 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
