Re: [PATCH V6 05/13] xfs: Check for extent overflow when growing realtime bitmap/summary inodes

Chandan Babu R
2021-03-24T14:18:52Z

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@kernel.org>
>>> >> Signed-off-by: Chandan Babu R <chandanrlinux@gmail.com>
>>> >
>>> > 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