Anything I should do with respect to this?
I.e. is further debug info needed for an interested developer? or can I
simply scrap that particular image (which is not an important one)?
Cheers,
Chris.
On Sun, 2019-03-17 at 04:42 +0100, Christoph Anton Mitterer wrote:
> (resending,... seems this hasn't gotten through to the list, when
> I've
> sent it the first time)
>
>
> Hi.
>
> On Debian's 4.19.28-2 kernel (which includes the recent read-
> corruption
> on compression fix) the following happens:
>
> As a consequence of the bug from the "Reproducer for "compressed data
> +
> hole data corruption bug, 2018 edition" still works on 4.20.7" mail
> thread I started (trying) to verify whether any of my data was
> affected.
>
> Part of this was looking for files which actually are compressed by
> the
> two methods Zygo mentioned (compsize and filefrag -v).
>
> For this I used two scripts like the attached ones (yes I know, bad
> performance) being fed by find path -type f -exec script {} \; .
>
>
> I've did this already on one of my disks, which I btrfs checked
> before
> (both normal and lowmem mode with no error), blockdev --setro'ed the
> device and mounted it ro.
>
> The filefrag seems to cause all kinds of errors and call traces,
> giving
> the dmesg output attached.
>
>
> Any ideas what causes that?
>
>
> These days I unfortunately strongly loose trust in the stability and
> integrity of btrfs :-(
>
>
> Cheers,
> Chris.
