Goswin von Brederlow posted on Sun, 16 Feb 2014 14:58:08 +0100 as excerpted: > As you can see there are still 270GiB free and plenty of block groups > free on the device too. > > So why isn't btrfs allocating a new block group to store more data? I saw this on a much (much) smaller filesystem a few weeks ago, when I redid my /boot. In my case it was under a gig total, so mixed-mode, but copying files over in a particular order errored some of them out with ENOSPC. But the way I was copying (using mc) left the ones that hadn't copied selected, and I tried a copy of them again, and/or used mc's directory-diff to find the missing files and copy them over again. After about three times, they all copied. So some combination of size and metadata wasn't triggering a new block allocation, but coming in a different order, it triggered fine. Again, this was mixed-mode, so data/metadata blocks mixed, and it didn't matter which ran out first since they were combined. I wonder if you're running into something similar. Can you try doing the copy in a different order, or is it one big file? -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
