On Tue, Aug 20, 2019 at 05:23:29PM +0300, Nikolay Borisov wrote: > > > On 16.08.19 г. 18:20 ч., Josef Bacik wrote: > > While messing with the overcommit logic I noticed that sometimes we'd > > ENOSPC out when really we should have run out of space much earlier. It > > turns out it's because we'll only reserve up to the free amount left in > > the space info for the global reserve, but that doesn't make sense with > > overcommit because we could be well above our actual size. This results > > in the global reserve not carving out it's entire reservation, and thus > > not putting enough pressure on the rest of the infrastructure to do the > > right thing and ENOSPC out at a convenient time. Fix this by always > > taking our full reservation amount for the global reserve. > > > > Signed-off-by: Josef Bacik <josef@xxxxxxxxxxxxxx> > > > In effect you could possibly overcommit by increasing bytes_may_use you > potentially cause callers of reserve_metadata_bytes to get ENOSPC, am I > right? In any case the code itself looks ok: > > Reviewed-by: Nikolay Borisov <nborisov@xxxxxxxx> > Right, again this is mostly for xfstests. We need to be able to provide the appropriate enospc pressure to make sure that we have enough space for the global reserve. In practice with real file systems we never end up pushing ourselves into overcommit with the giant global reserve by itself. Thanks, Josef
