diff mbox series

xfs quota test xfs/050 fails with dax mount option and "-d su=2m,sw=1" mkfs option

Message ID 20190724094317.4yjm4smk2z47cwmv@XZHOUW.usersys.redhat.com (mailing list archive)
State New, archived
Headers show
Series xfs quota test xfs/050 fails with dax mount option and "-d su=2m,sw=1" mkfs option | expand

Commit Message

Murphy Zhou July 24, 2019, 9:43 a.m. UTC 
Hi,

As subject.

-d su=2m,sw=1     && -o dax  fail
-d su=2m,sw=1     && NO dax  pass
no su mkfs option && -o dax  pass
no su mkfs option && NO dax  pass

On latest Linus tree. Reproduce every time.

Testing on older kernels are going on to see if it's a regression.

Is this failure expected ?

Thanks,
M

# fail with 2m su mkfs option and dax mount option:

FSTYP         -- xfs (debug)
PLATFORM      -- Linux/x86_64 7u 5.3.0-rc1-master-ad5e427+ #126 SMP Wed Jul 24 14:46:09 CST 2019
MKFS_OPTIONS  -- -f -f -b size=4096 -d su=2m,sw=1 /dev/pmem1
MOUNT_OPTIONS -- -o dax -o context=system_u:object_r:root_t:s0 /dev/pmem1 /test1

xfs/050 4s ...  [05:30:52] [05:30:56]- output mismatch (see /root/xfstests-dev/results//xfs/050.out.bad)
    --- tests/xfs/050.out       2019-05-07 02:34:03.391107482 -0400
    +++ /root/xfstests-dev/results//xfs/050.out.bad     2019-07-24 05:30:56.483044548 -0400
    @@ -29,6 +29,7 @@
     *** push past the hard block limit (expect EDQUOT)
     [ROOT] 0 0 0 00 [--------] 3 0 0 00 [--------] 0 0 0 00 [--------]
     [NAME] =OK= 200 1000 0 [7 days] 10 4 10 00 [7 days] 0 0 0 00 [--------]
    + URK 99: 2097152 is out of range! [3481600,4096000]

     *** unmount
     *** group
    ...
    (Run 'diff -u /root/xfstests-dev/tests/xfs/050.out /root/xfstests-dev/results//xfs/050.out.bad'  to see the entire diff)
Ran: xfs/050
Failures: xfs/050
Failed 1 of 1 tests

~
[root@7u ~]# diff -u /root/xfstests-dev/tests/xfs/050.out /root/xfstests-dev/results//xfs/050.out.bad


#Pass without dax:

FSTYP         -- xfs (debug)
PLATFORM      -- Linux/x86_64 7u 5.3.0-rc1-master-ad5e427+ #126 SMP Wed Jul 24 14:46:09 CST 2019
MKFS_OPTIONS  -- -f -f -b size=4096 /dev/pmem1
MOUNT_OPTIONS -- -o context=system_u:object_r:root_t:s0 /dev/pmem1 /test1

xfs/050         [05:30:35] [05:30:39] 4s
Ran: xfs/050
Passed all 1 tests

#Pass without 2m su mkfs option and with dax option:

FSTYP         -- xfs (debug)
PLATFORM      -- Linux/x86_64 7u 5.3.0-rc1-master-ad5e427+ #126 SMP Wed Jul 24 14:46:09 CST 2019
MKFS_OPTIONS  -- -f -f -b size=4096 /dev/pmem1
MOUNT_OPTIONS -- -o dax -o context=system_u:object_r:root_t:s0 /dev/pmem1 /test1

xfs/050 4s ...  [05:34:13] [05:34:17] 4s
Ran: xfs/050
Passed all 1 tests

# Pass with 2m su mkfs option and without dax mount option:

FSTYP         -- xfs (debug)
PLATFORM      -- Linux/x86_64 7u 5.3.0-rc1-master-ad5e427+ #126 SMP Wed Jul 24 14:46:09 CST 2019
MKFS_OPTIONS  -- -f -f -b size=4096 -d su=2m,sw=1 /dev/pmem1
MOUNT_OPTIONS -- -o context=system_u:object_r:root_t:s0 /dev/pmem1 /test1

xfs/050 4s ...  [05:36:08] [05:36:12] 4s
Ran: xfs/050
Passed all 1 tests

Comments

Dave Chinner July 29, 2019, 12:13 a.m. UTC | #1 
On Wed, Jul 24, 2019 at 05:43:17PM +0800, Murphy Zhou wrote:
> Hi,
> 
> As subject.
> 
> -d su=2m,sw=1     && -o dax  fail
> -d su=2m,sw=1     && NO dax  pass
> no su mkfs option && -o dax  pass
> no su mkfs option && NO dax  pass
> 
> On latest Linus tree. Reproduce every time.
> 
> Testing on older kernels are going on to see if it's a regression.
> 
> Is this failure expected ?

I'm not sure it's actually a failure at all. DAX does not do delayed
allocation, so if the write is aligned to sunit and at EOF it will
round the allocation up to a full stripe unit. IOWs, for this test
once the file size gets beyond sunit on DAX, writes will allocate in
sunit chunks.

And, well, xfs/050 has checks in it for extent size hints, and
notruns if:

        [ $extsize -ge 512000 ] && \
                _notrun "Extent size hint is too large ($extsize bytes)"

Because EDQUOT occurs when:

>     + URK 99: 2097152 is out of range! [3481600,4096000]

the file has less than 3.5MB or > 4MB allocated to it, and for a
stripe unit of > 512k, EDQUOT will occur at  <3.5MB. That's what
we are seeing here - a 2MB allocation at offset 2MB is > 4096000
bytes, and so it gets EDQUOT at that point....

IOWs, this looks like a test problem, not a code failure...

Cheers,

Dave.
Murphy Zhou July 29, 2019, 8:28 a.m. UTC | #2 
On Mon, Jul 29, 2019 at 10:13:08AM +1000, Dave Chinner wrote:
> On Wed, Jul 24, 2019 at 05:43:17PM +0800, Murphy Zhou wrote:
> > Hi,
> > 
> > As subject.
> > 
> > -d su=2m,sw=1     && -o dax  fail
> > -d su=2m,sw=1     && NO dax  pass
> > no su mkfs option && -o dax  pass
> > no su mkfs option && NO dax  pass
> > 
> > On latest Linus tree. Reproduce every time.
> > 
> > Testing on older kernels are going on to see if it's a regression.
> > 
> > Is this failure expected ?
> 
> I'm not sure it's actually a failure at all. DAX does not do delayed
> allocation, so if the write is aligned to sunit and at EOF it will
> round the allocation up to a full stripe unit. IOWs, for this test
> once the file size gets beyond sunit on DAX, writes will allocate in
> sunit chunks.
> 
> And, well, xfs/050 has checks in it for extent size hints, and
> notruns if:
> 
>         [ $extsize -ge 512000 ] && \
>                 _notrun "Extent size hint is too large ($extsize bytes)"
> 
> Because EDQUOT occurs when:
> 
> >     + URK 99: 2097152 is out of range! [3481600,4096000]
> 
> the file has less than 3.5MB or > 4MB allocated to it, and for a
> stripe unit of > 512k, EDQUOT will occur at  <3.5MB. That's what
> we are seeing here - a 2MB allocation at offset 2MB is > 4096000
> bytes, and so it gets EDQUOT at that point....
> 
> IOWs, this looks like a test problem, not a code failure...

Got it. Thanks Dave!

> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
diff mbox series

Patch

--- /root/xfstests-dev/tests/xfs/050.out        2019-05-07 02:34:03.391107482 -0400
+++ /root/xfstests-dev/results//xfs/050.out.bad 2019-07-24 05:30:56.483044548 -0400
@@ -29,6 +29,7 @@ 
 *** push past the hard block limit (expect EDQUOT)
 [ROOT] 0 0 0 00 [--------] 3 0 0 00 [--------] 0 0 0 00 [--------]
 [NAME] =OK= 200 1000 0 [7 days] 10 4 10 00 [7 days] 0 0 0 00 [--------]
+ URK 99: 2097152 is out of range! [3481600,4096000]

 *** unmount
 *** group
@@ -61,6 +62,7 @@ 
 *** push past the hard block limit (expect EDQUOT)
 [ROOT] 0 0 0 00 [--------] 3 0 0 00 [--------] 0 0 0 00 [--------]
 [NAME] =OK= 200 1000 0 [7 days] 10 4 10 00 [7 days] 0 0 0 00 [--------]
+ URK 99: 2097152 is out of range! [3481600,4096000]

 *** unmount
 *** uqnoenforce
@@ -157,6 +159,7 @@ 
 *** push past the hard block limit (expect EDQUOT)
 [ROOT] 0 0 0 00 [--------] 3 0 0 00 [--------] 0 0 0 00 [--------]
 [NAME] =OK= 200 1000 0 [7 days] 9 4 10 00 [7 days] 0 0 0 00 [--------]
+ URK 1: 2097152 is out of range! [3481600,4096000]

 *** unmount
 *** pqnoenforce