On Wed, Dec 02, 2015 at 02:39:32PM -0700, Ross Zwisler wrote: > On Thu, Dec 03, 2015 at 07:45:02AM +1100, Dave Chinner wrote: > > On Thu, Dec 03, 2015 at 07:29:10AM +1100, Dave Chinner wrote: > > > On Wed, Dec 02, 2015 at 11:34:38AM -0700, Ross Zwisler wrote: > > > > I'm hitting a few more test failures in my testing setup with v4.4-rc3, xfs > > > > and DAX. My test setup is a pair of 4GiB PMEM partitions in a KVM virtual > > > > machine. Here are the failures: > > > > > > Which are caused by commit 1ca1915 ("xfs: Don't use unwritten extents > > > for DAX") because of this code for unwritten extent conversion in > > > get_blocks: > > > > > > tp->t_flags |= XFS_TRANS_RESERVE; > > > > > > It's a minor problem compared to all the other issues DAX has right > > > now, so I ignored it to get the bigger problem solved first. > > > > Patch to fix the problem below. > > > > -Dave. > > -- > > Dave Chinner > > david@xxxxxxxxxxxxx > > > > xfs: Don't use reserved blocks for data blocks with DAX > > > > From: Dave Chinner <dchinner@xxxxxxxxxx> > > > > Commit 1ca1915 ("xfs: Don't use unwritten extents for DAX") enabled > > the DAX allocation call to dip into the reserve pool in case it was > > converting unwritten extents rather than allocating blocks. This was > > a direct copy of the unwritten extent conversion code, but had an > > unintended side effect of allowing normal data block allocation to > > use the reserve pool. Hence normal block allocation could deplete > > the reserve pool and prevent unwritten extent conversion at ENOSPC, > > hence violating fallocate guarantees on preallocated space. > > > > Fix it by checking whether the incoming map from __xfs_get_blocks() > > spans an unwritten extent and only use the reserve pool if the > > allocation covers an unwritten extent. > > > > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx> > > Tested-by: Ross Zwisler <ross.zwisler@xxxxxxxxxxxxxxx> > > I've verified that this fixes all three failing xfstests reported in this mail. > Thanks! Hey Dave, Are you planning on pushing this fix for v4.4? - Ross _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs