On Tue, Nov 20, 2018 at 12:20:40AM -0800, Christoph Hellwig wrote: > On Tue, Nov 20, 2018 at 08:04:58AM +1100, Dave Chinner wrote: > > From: Dave Chinner <dchinner@xxxxxxxxxx> > > > > Just tried to punch a 40T sparse file when enospc was triggered due > > to extent size hints consuming more space than expected. It failed > > with: > > > > # sudo xfs_io -c "fpunch 0 40t" /mnt/fast/xfs-arekm.img > > fallocate: No space left on device > > # > > > > 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. 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... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
