Opt-in non-fatal data csum mismatch handling?

Opt-in non-fatal data csum mismatch handling?

[Sun YangKai]

Hi btrfs developers and maintainers,

Many btrfs deployments run on consumer hardware — desktop PCs, home NAS 
boxes, laptops with no ECC RAM, USB-attached drives, consumer SSDs — 
environments where occasional data corruption are not rare. For many of 
these users, the data that fills most of the volume is also the data 
they care least about per-byte: BitTorrent downloads, build caches, 
browser caches, transcoded media, and so on. They would prefer "warn me 
and give me the data" over "fail the read with -EIO".

Today btrfs offers two ways out: `nodatasum` (and the `chattr +C` 
linkage) and `rescue=ignoredatacsums`. Both disable detection entirely, 
losing the diagnostic signal users might still want. The middle option — 
keep verifying, keep logging, but let the read succeed on mismatch — 
isn't available short of patching the kernel.

A possible interface: a mount option (e.g. `datacsum_action=warn`) that 
preserves the existing diagnostics — `btrfs_print_data_csum_error()` and 
the `BTRFS_DEV_STAT_CORRUPTION_ERRS` counter — but, after all 
mirror-repair attempts have failed, returns the corrupted data to the 
caller instead of `-EIO`. Disk-layer EIO from below the csum check would 
continue to propagate unchanged.

Before sketching a patch I wanted to ask:

1. Is the concept acceptable in principle, or is "never silently return 
corrupt data" a hard line for btrfs?
2. If acceptable, is "suppress csum-fail only, never disk EIO" the right 
boundary?
3. Are the existing diagnostic anchors (dev_stat counter + ratelimited 
dmesg) sufficient for the "warn" half, or would you want a statx/xattr 
surface as well?

Happy to send an RFC patch if the direction sounds reasonable.

Thanks,
Sun YangKai