On Sun, May 14, 2017 at 04:16:52PM -0700, Marc MERLIN wrote: > On Sun, May 14, 2017 at 09:21:11PM +0000, Hugo Mills wrote: > > > 2) balance -musage=0 > > > 3) balance -musage=20 > > > > In most cases, this is going to make ENOSPC problems worse, not > > better. The reason for doign this kind of balance is to recover unused > > space and allow it to be reallocated. The typical behaviour is that > > data gets overallocated, and it's metadata which runs out. So, the > > last thing you want to be doing is reducing the metadata allocation, > > because that's the scarce resource. > > > > Also, I'd usually recommend using limit=n, where n is approximately > > the amount of data overallcation (allocated space less used > > space). It's much more controllable than usage. > > > Thanks for that. > So, would you just remove the balance -musage=20 altogether?
Yes. > As for limit= I'm not sure if it would be helpful since I run this > nightly. Anything that doesn't get done tonight due to limit, would be > done tomorrow? I'm suggesting limit= on its own. It's a fixed amount of work compared to usage=, which may not do anything at all. For example, it's perfectly possible to have a filesystem which is, say, 30% full, and yet is still fully-allocated filesystem with more than 20% of every chunk used. In that case your usage= wouldn't balance anything, and you'd still be left in the situation of risking ENOSPC from running out of metadata. All you need to do is ensure that you have enough unallocated space for the metadata to expand into if it needs to. That's the ultimate goal of all this. If you have SSDs, it may also be beneficial to use nossd as a mount option, because that seems to have some pathology in overallocating chunks in normal usage. Hans investigated this in detail a month or two ago. Hugo. -- Hugo Mills | "You know, the British have always been nice to mad hugo@... carfax.org.uk | people." http://carfax.org.uk/ | PGP: E2AB1DE4 | Laura Jesson, Brief Encounter
signature.asc
Description: Digital signature
