11:54 p.m.
On Thu, Oct 01, 2015 at 02:31:21PM -0600, Ross Zwisler wrote:
On Thu, Oct 01, 2015 at 05:46:32PM +1000, Dave Chinner wrote:
> Hi folks,
>
> As discussed in the recent thread about problems with DAX locking:
>
> http://www.gossamer-threads.com/lists/linux/kernel/2264090?do=post_view_t...
>
> I said that I'd post the patch set that fixed the problems for XFS
> as soon as I had something sane and workable. That's what this
> series is.
>
> To start with, it passes xfstests "auto" group with only the only
> failures being expected failures or failures due to unexpected
> allocation patterns or trying to use unsupported block sizes. That
> makes it better than any previous version of the XFS/DAX code.
.....
Thank you for working on this, and for documenting your thinking so
clearly.
To put this in perspective, "patch 0" descriptions like this is a
requirement for any non-trivial XFS modification. It saves reviewers
so much time and many round trips in email and IRC to understand the
changes being proposed that it's a no-brainer.
Lead by example, and all that...
One thing I noticed is that in my test setup XFS+DAX is now failing
generic/274:
# diff -u tests/generic/274.out /root/xfstests/results//generic/274.out.bad
--- tests/generic/274.out 2015-08-24 11:05:41.490926305 -0600
+++ /root/xfstests/results//generic/274.out.bad 2015-10-01 13:53:50.498354091 -0600
@@ -2,4 +2,5 @@
------------------------------
preallocation test
------------------------------
-done
+failed to write to test file
+(see /root/xfstests/results//generic/274.full for details)
I've verified that the test passes 100% of the time with my baseline
(v4.3-rc3), and with the set applied but without the DAX mount option. With
the series and with DAX it fails 100% of the time. I haven't looked into the
details of the failure yet, I just wanted to let you know that it was
happening.
See above - I classified this under the "failures due to unexpected
allocation patterns". This is a ENOSPC test, and we've change the
allocation pattern and the unwritten extent conversion algorithm and
so changed the metadata allocation demand of the test.
I haven't looked any further than this yet, but I suspect the issue
is that the up-front unwritten extent conversion is not being
allowed to dip into the reserve block pool for BMBT allocations when
the extent list grows past a single block. If that's the case, then
it's a couple of lines of code to conditionally at XFS_TRANS_RESERVE
to the transaction handle to allow it access to the reserve pool...
Cheers,
Dave.
--
Dave Chinner
david(a)fromorbit.com