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 > [email protected] _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
