On 2019/2/13 下午3:47, Roman Mamedov wrote:
> On Mon, 11 Feb 2019 22:09:02 -0500
> Zygo Blaxell <ce3g8jdj@umail.furryterror.org> wrote:
> 
>> Still reproducible on 4.20.7.
>>
>> The behavior is slightly different on current kernels (4.20.7, 4.14.96)
>> which makes the problem a bit more difficult to detect.
>>
>> 	# repro-hole-corruption-test
>> 	i: 91, status: 0, bytes_deduped: 131072
>> 	i: 92, status: 0, bytes_deduped: 131072
>> 	i: 93, status: 0, bytes_deduped: 131072
>> 	i: 94, status: 0, bytes_deduped: 131072
>> 	i: 95, status: 0, bytes_deduped: 131072
>> 	i: 96, status: 0, bytes_deduped: 131072
>> 	i: 97, status: 0, bytes_deduped: 131072
>> 	i: 98, status: 0, bytes_deduped: 131072
>> 	i: 99, status: 0, bytes_deduped: 131072
>> 	13107200 total bytes deduped in this operation
>> 	am: 4.8 MiB (4964352 bytes) converted to sparse holes.
>> 	94a8acd3e1f6e14272f3262a8aa73ab6b25c9ce8 am
>> 	6926a34e0ab3e0a023e8ea85a650f5b4217acab4 am
>> 	6926a34e0ab3e0a023e8ea85a650f5b4217acab4 am
>> 	6926a34e0ab3e0a023e8ea85a650f5b4217acab4 am
>> 	6926a34e0ab3e0a023e8ea85a650f5b4217acab4 am
>> 	6926a34e0ab3e0a023e8ea85a650f5b4217acab4 am
>> 	6926a34e0ab3e0a023e8ea85a650f5b4217acab4 am
> 
> Seems like I can reproduce it as well. Vanilla 4.14.97 with .config loosely
> based on Debian's.
> 
> $ sudo ./repro-hole-corruption-test 
> i: 91, status: 0, bytes_deduped: 131072
> i: 92, status: 0, bytes_deduped: 131072
> i: 93, status: 0, bytes_deduped: 131072
> i: 94, status: 0, bytes_deduped: 131072
> i: 95, status: 0, bytes_deduped: 131072
> i: 96, status: 0, bytes_deduped: 131072
> i: 97, status: 0, bytes_deduped: 131072
> i: 98, status: 0, bytes_deduped: 131072
> i: 99, status: 0, bytes_deduped: 131072
> 13107200 total bytes deduped in this operation
> am: 4.8 MiB (4964352 bytes) converted to sparse holes.
> c5f25fc2b88eaab504a403465658c67f4669261e am
> 1d9aacd4ee38ab7db46c44e0d74cee163222e105 am
> 6926a34e0ab3e0a023e8ea85a650f5b4217acab4 am
> 6926a34e0ab3e0a023e8ea85a650f5b4217acab4 am
> 6926a34e0ab3e0a023e8ea85a650f5b4217acab4 am
> 6926a34e0ab3e0a023e8ea85a650f5b4217acab4 am
> 6926a34e0ab3e0a023e8ea85a650f5b4217acab4 am
> 6926a34e0ab3e0a023e8ea85a650f5b4217acab4 am
> 6926a34e0ab3e0a023e8ea85a650f5b4217acab4 am
> 6926a34e0ab3e0a023e8ea85a650f5b4217acab4 am
> 6926a34e0ab3e0a023e8ea85a650f5b4217acab4 am
> 6926a34e0ab3e0a023e8ea85a650f5b4217acab4 am
> 
> The above is on a 3TB spinning disk. But on a 512GB NVMe SSD I even got the
> same checksums as you did.
> 
> $ sudo ./repro-hole-corruption-test 
> i: 91, status: 0, bytes_deduped: 131072
> i: 92, status: 0, bytes_deduped: 131072
> i: 93, status: 0, bytes_deduped: 131072
> i: 94, status: 0, bytes_deduped: 131072
> i: 95, status: 0, bytes_deduped: 131072
> i: 96, status: 0, bytes_deduped: 131072
> i: 97, status: 0, bytes_deduped: 131072
> i: 98, status: 0, bytes_deduped: 131072
> i: 99, status: 0, bytes_deduped: 131072
> 13107200 total bytes deduped in this operation
> am: 4.8 MiB (4964352 bytes) converted to sparse holes.
> 94a8acd3e1f6e14272f3262a8aa73ab6b25c9ce8 am
> 6926a34e0ab3e0a023e8ea85a650f5b4217acab4 am
> 6926a34e0ab3e0a023e8ea85a650f5b4217acab4 am
> 6926a34e0ab3e0a023e8ea85a650f5b4217acab4 am
> 
> In my case both filesystems are not mounted with compression,

OK, I forgot the compression mount option.

Now I can reproduce it too, both host and VM now.
I'll try to make the test case minimal enough to avoid too many noise
during test.

Thanks,
Qu

> just chattr +c of
> the directory with the script is enough to see the issue.
>