On Tue, Nov 20, 2018 at 08:50:42PM +1100, Dave Chinner wrote: > > > because the writeback error of ENOSPC was being reported. We're > > > going to free that space, so we don't care if there was a ENOSPC > > > writeback error. So ignore ENOSPC errors and punch anyway. > > > > How do even get -ENOSPC back from writeback? It seems like we have > > a much worse root cause lingering here. > > It hammered ENOSPC pretty hard - I think it had consumed the entire > reserve pool and that can causes allocation transaction reservations > in xfs_iomap_write_allocate() to return ENOSPC even if we've got a > reservation for the data extents being allocated. Well, that means we do have a problem somewhere in our accounting, as writeback should not run into ENOSPC. > This doesn't happen very often in the real world, but if it does we > need operations like punch to work to be able to free space and > get us out of that hole... I'm ok(-ish) with the patch, but I wish we could also sort out the root cause..
