On Mon, 11 Feb 2019 22:09:02 -0500 Zygo Blaxell <ce3g8...@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, just chattr +c of the directory with the script is enough to see the issue. -- With respect, Roman
