Re: bad file extent, some csum missing - how to check that restored volumes are error-free?

[Dave T <davestechshop@gmail.com>]

> OK, lowmem mode indeed did a much better job.
>
> This is a very strange bug.
>
> This means:
>
> - The compressed extent doesn't have csum
>    Which shouldn't be possible for recent kernels.
>
> - The compressed extent exists for inode which has NODATASUM flag
>    Not possible again for recent kernels.
>
> But IIRC there are old kernels allowing such compression + nodatasum.
>
> I guess that's the reason why you got EIO when reading it.
>
> When we failed to find csum, we just put 0x00 as csum, and then when you
> read the data, it's definitely going to cause csum mismatch and nothing
> get read out.
>
> This can be worked around by recent "rescue=idatacsums" mount option.
>
> But to me, this really looks like some old fs, with some inodes created
> by older kernels.

I'm running:
kernel version 5.12.15-arch1-1 (linux@archlinux)

I've been running arch + btrfs since 2014. I keep arch linux fully
updated. I'm running new kernels and new btrfs progs. However, I
created this filesystem around 2014.

Is there an option to "update" my BTRFS filesystem? Is that even a thing?

I have multiple devices running on BTRFS filesystems created around
2014 to 2016. Are those all in danger of having some problems now?
BTRFS has been mostly problem-free for me since before 2014. I do
regular balance and scrubs. However, I'm getting worried about my data
now...

I hope I do not need to backup every device, recreate the filesystems,
and restore them. That would be weeks of work and I'm already
overworked... but losing data would be worse.

BTW, even my backup disks run on BTRFS filesystems that were created years ago.

> > Are any of these options appropriate?
> >
> > -  btrfs rescue chunk-recover /dev/mapper/xyz
>
> Definite no.
>
> Any rescue command should only be used when some developer suggested.

Thank you for reminding me! There's a lot of bad BTRFS advice on all
the various forums, and it is easy to be influenced by it when you are
a casual user like me.


> > - btrfs check --repair --init-csum-tree /dev/mapper/xyz
>
> This may solve the read error, but we will still report the NODATACSUM
> problem for the compressed extent.
>
> Have you tried to remove the NODATASUM option for those involved inodes?

https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs(5)
says:
Note: If compression is enabled, nodatacow and nodatasum are disabled.

My mount options are:
rw,autodefrag,noatime,nodiratime,compress=lzo,space_cache,subvol=xyz

Do I understand it correctly? My compression option should already
"remove the NODATASUM".

>
> If it's possible to remove NODATASUM for those inodes, then
> --init-csum-tree should be able to solve the problem.

What do you recommend now?