On Freitag, 4. März 2016 12:31:44 CEST Duncan wrote: > Dāvis Mosāns posted on Thu, 03 Mar 2016 17:39:12 +0200 as excerpted: > > 2016-03-03 6:57 GMT+02:00 Duncan <1i5t5.dun...@cox.net>: > >> You're issue isn't the same, because all your space was allocated, > >> leaving only 1 MiB unallocated, which isn't normally enough to allocate > >> a new chunk to rewrite the data or metadata from the old chunks into. > >> > >> That's a known issue, with known workarounds as dealt with in the FAQ. > > > > Ah, thanks, well it was surprising for me that balance failed with out > > of space when both data and metadata had not all been used and I thought > > it could just use space from those... > > > > especially as from FAQ: > >> If there is a lot of allocated but unused data or metadata chunks, > >> a balance may reclaim some of that allocated space. This is the main > >> reason for running a balance on a single-device filesystem. > > > > so I think regular balance should be smart enough that it could solve > > this on own and wouldn't need to specify any options. > > Well it does solve the problem on its own... to the extent that it > eliminates empty chunks (kernel 3.17+, it didn't before that). But if > there's even a single 4 KiB file block used in the (nominal 1 GiB sized > data) chunk, it's no longer empty and thus not eliminated by the empty > chunk cleanup routines.
It could theoretically copy part of one almost empty chunk into another chunk to free it up, couldn´t it? This way it can free some chunks completely and then start the regular balance? In either case, its unintuitive for the user to fail this. The filesystem tools should allow a balance in *any* case without needing special treatment by the user. Thanks, -- Martin -- 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
