On Wed, Sep 24, 2014 at 6:23 PM, Holger Hoffstätte <holger.hoffstaette@xxxxxxxxxxxxxx> wrote: >> Basically it's been data allocation happy, since I haven't deleted >> 53GB at any point. Unfortunately, none of the chunks are at 0% usage >> so a balance -dusage=0 finds nothing to drop. > > Also try -musage=0..10, just for fun. Tried a few of them. When it's completely wedged, balance with any usage above zero won't work, because it needs one allocatable group to move to. I'm not sure if it was needing a new data chunk to merge partials into, or if it thought it needed more metadata space to write out the changes. (Metadata was also only 75% used). >> Is this recoverable, or do I need to copy to another disk and back? > > Another neat trick that will free up space is to convert to single > metadata: -mconvert=single -f (to force). A subsequent balance > with -musage=0..10 will likely free up quite some space. Deleting files or dropping snapshots is difficult when it's wedged as well, a lot of disk activity (journal thrash?) and no persistent progress - a reboot brigs the deleted files back. I eventually managed to empty a single data chunk and after that it was a trivial recovery. > That particular workload seems to cause the block allocator to go > on a spending spree; you're not the first to see this. I could see normal-user usage patterns getting ignored, but this is the patterns of the people working on BTRFS. Maybe they need to remove their balance cronjobs for a while. :) -- 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
