Re[2]: parent transid verify failed: Fixed but re-appearing

["Hendrik Friedel" <hendrik@friedels.name>]

Hello Zygo, hello Lakshmipathi,

@Lakshmipathi: as you suggested I consulted the BTRFS-Mailing list on 
this issue:
https://github.com/Lakshmipathi/dduper/issues/39

Zygo was so kind to help me and he suspects the error to lie within 
dduper.
>>  > > Sure, more scrubs are better.  They are supposed to be run regularly
>>  > > to detect drives going bad.
>>  > btrfs scrub start -Bd /dev/sda1
>>  >
>>  >
>>  > scrub device /dev/sda1 (id 1) done
>>  >         scrub started at Wed Oct 21 23:38:36 2020 and finished after 13:45:29
>>  >         total bytes scrubbed: 6.56TiB with 0 errors
>>  >
>>  > But then again:
>>  > dduper --device /dev/sda1 --dir /srv/dev-disk-by-label-DataPool1/dduper_test/testfiles -r --dry-run
>>  > parent transid verify failed on 16500741947392 wanted 358407 found 358409
>>  > Ignoring transid failure
>
>Wait...is that the kernel log, or the output of the dduper command?
>
It is on the commandline once I run the command; thus I suspect it is 
the dduper output. But of course sometimes the Kernel-Messages appear 
directly on the commandline. I do not know how to tell.

>
>commit 3e5f67f45b553045a34113cafb3c22180210a19f (tag: v0.04, origin/dockerbuild)
>Author: Lakshmipathi <lakshmipathi.ganapathi@collabora.com>
>Date:   Fri Sep 18 11:51:42 2020 +0530
>
>file deduper:
>
>     194 def btrfs_dump_csum(filename):
>     195     global device_name
>     196
>     197     btrfs_bin = "/usr/sbin/btrfs.static"
>     198     if os.path.exists(btrfs_bin) is False:
>     199         btrfs_bin = "btrfs"
>     200
>     201     out = subprocess.Popen(
>     202         [btrfs_bin, 'inspect-internal', 'dump-csum', filename, device_name],
>     203         stdout=subprocess.PIPE,
>     204         close_fds=True).stdout.readlines()
>     205     return out
>
>OK there's the problem:  it's dumping csums from a mounted filesystem by
>reading the block device instead of using the TREE_SEARCH_V2 ioctl.
>Don't do that, because it won't work.  ;)
I trust you on this ;-) But I am surprised I am the only one reporting 
this issue. Will it *always* not work, or does it not work in some cases 
and my situation is making it extremely unlikely to work?
>
>The "parent transid verify failed" errors are harmless.  They are due
>to the fact that a process reading the raw block device can never build
>an accurate model of a live filesystem that is changing underneathi it.
>
>If you manage to get some dedupe to happen, then that's a bonus.
>
>
>>  >
>>  > > >  Anything else, I can do?
>>  > >
>>  > > It looks like sda1 might be bad and it is working by replacing lost
>>  > > data from the mirror on sdj.  But this replacement should be happening
>>  > > automatically on read (and definitely on scrub), so you shouldn't ever
>>  > > see the same error twice, but it seems that you do.
>>  >
>>  > Well, it is not the same error twice.
>
>Earlier you quoted some duplicate lines.  Normally those get fixed after the
>first line, so you never see the second.
>
I see.

Regards,
Hendrik