btrfs corruption bug! kvm/qemu + cache=none (+snapshotok) miatt...

persze oldalakon at... es a "btrfs check --force --readonly /dev/md5" meg vagy 1000 oldalnyi errort irt ki...

de ami meglepo, hogy ennek ellenere a qemu vm-ek es a kontenerek is gond nelkul futnak!

megprobaltam egy masik diskre atpakolni, hogy az elszarodott btrfs disket leformazzam, es ekkor ert a meglepi: az lxc-ket gond nelkul atmasolta, de a qemu imageknel par100 mega utan i/o errort ir, egyszeruen nem lehet lemasolni.  ddrescue-val igen, hibakkal, de a masolat nem mukodokepes, mig az eredeti igen!

raguglizva konkretan sikerult talalni par bejegyzest, tehat ez egy letezo problema, amibe szokoevente mas is belefut, de nem annyian hogy kijavitsak...

Description of problem:
Btrfs does checksumming so if it reads back data and the checksum doesn't look right it will complain and return EIO.  I spent some time debugging a problem with installing a Windows 7 box on Btrfs via kvm and using Cache=None, and it looked like Btrfs was corrupting the file.

https://bugzilla.redhat.com/show_bug.cgi?id=693530

https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg92759.html

After a long while I think I discovered what triggers this. If you use a raw image file for your Windows VM and use cache = none, these errors start up pretty quickly from normal use

https://forums.unraid.net/topic/121767-btrfs-corruption/

ha jol ertem, az van, hogy a qemu RAW modban (cache=none) kikeruli a btrfs checksum szamolasat, igy a btrfs szerint hibas imaget gond nelkul tudja hasznalni, de siman lemasolni nem lehet, mert akkor a btrfs latja a checksum eltereseket...

mar csak az a kerdes, vajon hogy lehet egy ilyen imaget megis lemasolni?  (kb az a zotletem hogy felhuzok egy linuxot qemu-ban ami ala becsatolom raw modban ezt az imaget meg egy masikat es a vm-en belul dd-zem at)

talan 5.17-ben megis javitottak? nalam 5.15 volt, most frissitettem 5.19-re, meglatjuk:

https://lore.kernel.org/linux-btrfs/YrrFGO4A1jS0GI0G@atmark-techno.com/…

So cache=none means O_DIRECT and using io_uring. This really sounds 
similar to:

ca93e44bfb5fd7996b76f0f544999171f647f93b

This commit got merged into v5.17 so you shouldn't be seeing it on 5.17 
and onwards.