lkml.org 
[lkml]   [2015]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: [PATCH 0/7] xfs, dax: fix the page fault/allocation mess
    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_threaded
    > >
    > > 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@fromorbit.com


    \
     
     \ /
      Last update: 2015-10-02 01:21    [W:2.415 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site