On 2019/2/13 下午3:47, Roman Mamedov wrote: > On Mon, 11 Feb 2019 22:09:02 -0500 > Zygo Blaxell <ce3g8jdj@xxxxxxxxxxxxxxxxxxxxx> 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. >
Attachment:
signature.asc
Description: OpenPGP digital signature
