On Fri, Mar 04, 2016 at 12:31:44PM +0000, 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. > > Additionally, balance, which was originally called the restriper,
Nope, balance was always called balance. The restriper was the balance feature that's now called "convert". :) Hugo. by > definition, must have enough space to create at least one empty chunk in > ordered to copy the data from existing chunks into, such that it can > consolidate that data into fewer new chunks when the old ones were partly > empty. If there's not enough unallocated space left to write even one > chunk, balance can't do its thing, because there's nowhere to create the > new chunk it needs to be able to copy over the data from the old chunk. > > With nominal 1 GiB data chunk size (up to 10 GiB in some instances if the > filesystem is large enough), that means you need at least 1 GiB of free > unallocated space in ordered to have room to create that single chunk > that starts the rewrite process off. Without it, you're stuck, tho there > are workarounds like trying to balance the smaller (256 MiB nominal) > metadata chunks first, hoping that frees the minimum 1 GiB space needed > for a data chunk, or temporarily adding another device a few GiB in size > to the filesystem, to give it somewhere to write the new chunk to so it > can start off the rewrite and shrinking process. > -- Hugo Mills | Darkling's First Law of Filesystems: hugo@... carfax.org.uk | The user hates their data http://carfax.org.uk/ | PGP: E2AB1DE4 |
signature.asc
Description: Digital signature
