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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
-- 
Dave Chinner
david@xxxxxxxxxxxxx



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux