]> git.ipfire.org Git - thirdparty/xfsprogs-dev.git/commit
xfs: don't rely on ->total in xfs_alloc_space_available libxfs-4.10-sync
authorChristoph Hellwig <hch@lst.de>
Wed, 11 Jan 2017 02:09:21 +0000 (20:09 -0600)
committerEric Sandeen <sandeen@redhat.com>
Wed, 11 Jan 2017 02:09:21 +0000 (20:09 -0600)
commit3fe4a6dd012841c30a6d21c42e390947f8304480
tree50a8713eed3445b7e5aa00ea35a735f74dbe2fb7
parent2c003dc253b4c8d4313c4f633ebc8ee649bf1d6b
xfs: don't rely on ->total in xfs_alloc_space_available

Source kernel commit: 12ef830198b0d71668eb9b59f9ba69d32951a48a

->total is a bit of an odd parameter passed down to the low-level
allocator all the way from the high-level callers.  It's supposed to
contain the maximum number of blocks to be allocated for the whole
transaction [1].

But in xfs_iomap_write_allocate we only convert existing delayed
allocations and thus only have a minimal block reservation for the
current transaction, so xfs_alloc_space_available can't use it for
the allocation decisions.  Use the maximum of args->total and the
calculated block requirement to make a decision.  We probably should
get rid of args->total eventually and instead apply ->minleft more
broadly, but that will require some extensive changes all over.

[1] which creates lots of confusion as most callers don't decrement it
once doing a first allocation.  But that's for a separate series.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
libxfs/xfs_alloc.c