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

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

Hello Zygo,

thanks for your reply.
>To be clear, scrub is the first thing to try, it will try to walk all
>the trees on the filesystem and read all the blocks.
>
Understood. Also thanks for explaining the other two options.
I think, it would be really advisable to add some recipies in the btrfs 
wiki - especially because btrfs check --repair is often not the right 
option opposed to the equivalent on other file systems.

>>  > Scrub iterates over all metadata pages and should hit ptvf if it's
>>  > on disk.
>>
>>  But apparently it did not?!
>
>...which indicates the problem is probably in memory, not on disk.

Which is good. On the other hand, that leaves the question why I have 
re-occuring failures of this kind (apparently) in memory.
What are possible reasons?

>>  So it looks like it is raid1 metadata
>
>That would mean either that recovery already happened (if the corruption
>was on disk and has been removed), or the problem never reached a disk
>(if it is only in memory).
Ok.
Good news.

But it's still there:
dduper --device /dev/sda1 --dir 
/srv/dev-disk-by-label-DataPool1/dduper_test/testfiles -r --dry-run
parent transid verify failed on 8333716668416 wanted 357026 found 357028
parent transid verify failed on 8333716668416 wanted 357026 found 357028
parent transid verify failed on 8333716668416 wanted 357026 found 357028


>
>>  > only one of your disks is silently dropping writes.  In that case
>>  > btrfs will recover from ptvf by replacing the missing block from the
>>  > other drive.  But there are no scrub errors or kernel messages related
>>  > to this, so there aren't any symptoms of that happening, so it seems
>>  > these ptvf are not coming from the disk.
>>  And can this be confirmed somehow? Would be good to replace that disk
>>  then...
>
>These normally appear in 'btrfs dev stats', although there are various
>coverage gaps with raid5/6 and (until recently) compressed data blocks.
I do not use raid5/6 and I think I do not use compressed data.

btrfs dev stats /dev/sda1
[/dev/sda1].write_io_errs    0
[/dev/sda1].read_io_errs     0
[/dev/sda1].flush_io_errs    0
[/dev/sda1].corruption_errs  0
[/dev/sda1].generation_errs  1

So, what does the generation_errs tell us?

>'btrfs scrub status -d' will give a per-drive error breakdown.

btrfs scrub status -d /dev/sda1
scrub status for c4a6a2c9-5cf0-49b8-812a-0784953f9ba3
scrub device /dev/sda1 (id 1) history
         scrub started at Mon Oct 19 21:07:13 2020 and finished after 
15:11:10
         total bytes scrubbed: 6.56TiB with 0 errors

btrfs scrub status -d /dev/sdj1
scrub status for c4a6a2c9-5cf0-49b8-812a-0784953f9ba3
scrub device /dev/sdj1 (id 2) history
         scrub started at Mon Oct 19 21:07:13 2020 and finished after 
17:06:15
         total bytes scrubbed: 6.56TiB with 0 errors


>I haven't seen spurious ptvf errors on my test machines since the 5.4.30s,
>but 5.4 has a lot of fixes that between-LTS kernels like 5.6 do not
>always get.

Ok, I am compiling 5.9.1 now.

Apart from switching to the latest Kernel - what next step do you 
recommend?
I tend to run a scrub again. Is it possible/useful to make it more 
verbose?
What else?

Greetings,
Hendrik