On Sun, Aug 02, 2015 at 12:31:13PM -0600, Chris Murphy wrote: > On Sat, Aug 1, 2015 at 9:46 PM, Duncan <1i5t5.dun...@cox.net> wrote: > > > If it was setup with something earlier (not sure about 4.1.0, was it > > affected? > > No. > > > but 4.0.x and earlier should be fine for setup), however, once > > on a new kernel the usual ENOSPC workarounds can be given a try. That > > would include a first balance start -dusage=0 -musage=0, and if that > > didn't free up at least a gig on a second device, > > If I'm following this correctly, the reproduce steps would be to > create a single device Btrfs that's ~94% full, add two devices, then > convert to raid5. I think what's going on here is empty single profile > data chunks aren't being deallocated, and it's effectively a 2 device > raid5.
This isn't supported by the btrfs fi df output: all of the allocated space is used. Hugo. > So actually, you're right, either -dusage=0 might fix it, or better, > newer kernel that automatically deallocated empty/converted single > profile data chunks. But right now it will take another balance in the > end because it looks like this is effectively a 2 device raid5, with > the 3rd drive full of single only chunks (which might be empty?). -- Hugo Mills | I'll take your bet, but make it ten thousand francs. hugo@... carfax.org.uk | I'm only a _poor_ corrupt official. http://carfax.org.uk/ | PGP: E2AB1DE4 | Capt. Renaud, Casablanca
signature.asc
Description: Digital signature
