Darrick J. Wong f310bd2ecd xfs: account for the refcount btree in the alloc/free log reservation
Every time we allocate or free a data extent, we might need to split
the refcount btree.  Reserve some blocks in the transaction to handle
this possibility.  Even though the deferred refcount code can roll a
transaction to avoid overloading the transaction, we can still exceed
the reservation.

Certain pathological workloads (1k blocks, no cowextsize hint, random
directio writes), cause a perfect storm wherein a refcount adjustment
of a large range of blocks causes full tree splits in two separate
extents in two separate refcount tree blocks; allocating new refcount
tree blocks causes rmap btree splits; and all the allocation activity
causes the freespace btrees to split, blowing the reservation.

(Reproduced by generic/167 over NFS atop XFS)

Signed-off-by: Christoph Hellwig <hch@lst.de>
[darrick.wong@oracle.com: add commit message]
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
2016-10-03 09:11:19 -07:00
..
2016-06-10 18:14:47 -07:00
2016-05-20 17:58:30 -07:00
2016-08-07 10:03:31 -04:00
2016-08-12 12:32:24 -07:00
2016-07-29 12:05:25 +02:00
2016-05-23 17:04:14 -07:00
2016-07-27 09:53:35 -07:00
2016-06-07 22:07:09 -04:00
2016-08-04 19:59:06 -04:00
2016-06-20 17:11:29 -04:00
2016-07-01 10:24:18 -04:00
2016-06-21 09:23:11 +10:00
2016-08-07 10:03:31 -04:00
2016-07-26 16:19:19 -07:00
2016-08-07 10:03:31 -04:00