On Mon, Aug 04, 2014 at 02:17:02PM +0100, Peter Waller wrote: > For anyone else having this problem, this article is fairly useful for > understanding disk full problems and rebalance: > > http://marc.merlins.org/perso/btrfs/post_2014-05-04_Fixing-Btrfs-Filesystem-Full-Problems.html > > It actually covers the problem that I had, which is that a rebalance > can't take place because it is full. > > I still am unsure what is really wrong with this whole situation. Is > it that I wasn't careful to do a rebalance when I should have been > doing? Is it that BTRFS doesn't do a rebalance automatically when it > could in principle?
This latter one. Well, actually two things: the FS should be capable of autonomously rebalancing at low bandwidth to prevent this problem, but nobody's got round to implementing it yet. Secondly, it should not be possible to get into a state where you can't run the balance -- Josef spent about three kernel revisions fixing the block reserve code to that end. However, since about 3.14, there's been more cases like yours show up, so I think there's been a regression. It's not very common, though. I think we've had maybe a dozen reported instances in the last 6 months. Someone on IRC had it just now, though, and captured a metadata image, so at least we've got some (meta)data to work with now. > It's pretty bad to end up in a situation (with spare space) where the > only way out is to add more storage, which may be impractical, > difficult or expensive. > > The other thing that I still don't understand I've seen repeated in a > few places, from the above article: > > "because the filesystem is only 55% full, I can ask balance to rewrite > all chunks that are more than 55% full" > > Then he uses `btrfs balance start -dusage=55 /mnt/btrfs_pool1`. I > don't understand the relationship between "the FS is 55% full" and > "chunks more than 55% full". What's going on here? Pigeonhole principle -- if the FS is 55% full, there must be at least one chunk <= 55% full. > I conclude that now since I have added more storage, the rebalance > won't fail and if I keep rebalancing from a cron job I won't hit this > problem again (unless the filesystem fills up very fast! what then?). > I don't know however what value to assign to `-dusage` in general for > the cron rebalance. Any hints? Try with increasing values until you've moved as many chunks as you want to. This is what David's "balance at least N chunks" patch did. I'd suggest start with 5, and go up in increments of 5, if you're making it an automatic process. Stop when you reach some threshold (like, say, 80), or when it reports that it's actually moved some chunks. Doing it manually, I usually recommend 5, 10, 20, 50, 80. Hugo. > -- > 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 -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Well, you don't get to be a kernel hacker simply by looking --- good in Speedos. -- Rusty Russell
signature.asc
Description: Digital signature
