Re: LMDB mdb_copy produces a corrupt database on btrfs, but not on ext4

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2023/2/16 07:21, Boris Burkov wrote:
> On Wed, Feb 15, 2023 at 03:16:39PM -0500, Chris Murphy wrote:
>>
>>
>> On Wed, Feb 15, 2023, at 3:04 PM, Chris Murphy wrote:
>>> Downstream bug report, reproducer test file, and gdb session transcript
>>> https://bugzilla.redhat.com/show_bug.cgi?id=2169947
>>>
>>> I speculated that maybe it's similar to the issue we have with VM's
>>> when O_DIRECT is used, but it seems that's not the case here.
>>
>> I can reproduce the mismatching checksums whether the test files are datacow or nodatacow (using chattr +C). There are no kernel messages during the tests.
>>
>> kernel 6.2rc7 in my case; and in the bug report kernel series 6.1, 6.0, and 5.17 reproduce the problem.
>>
> 
> I was also able to reproduce on the current misc-next. However, when I
> hacked the kernel to always fall back from DIO to buffered IO, it no
> longer reproduced. So that's one hint..
> 
> The next observation comes from comparing the happy vs unhappy file
> extents on disk:
> happy: https://pastebin.com/k4EPFKhc
> unhappy: https://pastebin.com/hNSBR0yv
> 
> The broken DIO case is missing file extents between bytes 8192 and 65536
> which corresponds to the observed zeros.
> 
> Next, at Josef's suggestion, I looked at the IOMAP_DIO_PARTIAL and
> instrumented that codepath. I observed a single successful write to 8192
> bytes, then a second write which first does a partial write from 8192 to
> 65536 and then faults in the rest of the iov_iter and finishes the
> write.

A little off-topic, as I'm not familiar with Direct IO at all.

That fault (I guess means page fault?) means the Direct IO source 
(memory of the user space program) can not be accessible right now?
(being swapped?)

If that's the case, any idea why we can not wait for the page fault to 
fill the user space memory?
I guess it's some deadlock but is not for sure.

Thanks,
Qu
> 
> I'm now trying to figure out how these partial writes might lead us to
> not create all the EXTENT_DATA items for the file extents.
> 
> Boris
> 
>>
>> -- 
>> Chris Murphy