Re: delayed_refs has NO entry / btrfs_update_root:136: Aborting unused transaction(No space left).

[Christoph Anton Mitterer <calestyo@scientia.net>]

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.