On 24 Mar 2021 at 16:16, Chandan Babu R wrote: > On 24 Mar 2021 at 02:27, Darrick J. Wong wrote: >> On Tue, Mar 23, 2021 at 09:21:27PM +0530, Chandan Babu R wrote: >>> On 22 Mar 2021 at 23:26, Darrick J. Wong wrote: >>> > On Tue, Mar 09, 2021 at 10:31:16AM +0530, Chandan Babu R wrote: >>> >> Verify that XFS does not cause realtime bitmap/summary inode fork's >>> >> extent count to overflow when growing the realtime volume associated >>> >> with a filesystem. >>> >> >>> >> Reviewed-by: Darrick J. Wong <djwong@xxxxxxxxxx> >>> >> Signed-off-by: Chandan Babu R <chandanrlinux@xxxxxxxxx> >>> > >>> > Soo... I discovered that this test doesn't pass with multiblock >>> > directories: >>> >>> Thanks for the bug report and the description of the corresponding solution. I >>> am fixing the tests and will soon post corresponding patches to the mailing >>> list. >> >> Also, I found a problem with xfs/534 when it does the direct write tests >> to a pmem volume with DAX enabled: >> >> --- /tmp/fstests/tests/xfs/534.out 2021-03-21 11:44:09.384407426 -0700 >> +++ /var/tmp/fstests/xfs/534.out.bad 2021-03-23 13:32:15.898301839 -0700 >> @@ -5,7 +5,4 @@ >> Fallocate 15 blocks >> Buffered write to every other block of fallocated space >> Verify $testfile's extent count >> -* Direct write to unwritten extent >> -Fallocate 15 blocks >> -Direct write to every other block of fallocated space >> -Verify $testfile's extent count >> +Extent count overflow check failed: nextents = 11 > > The inode extent overflow reported above was actually due to the buffered > write operation. But it does occur with direct write operation as well. I just found out that xfs_direct_write_iomap_ops is used for both buffered and direct IO w.r.t dax devices. Please ignore the above statement. -- chandan
