hello we use kvm with disks formatted in btrfs when we turned on the mode "cache=none" got data corruption other modes work well we tested it on three servers and the result is always repeated we tested on three operating systems(debian 9, debian 10, manjaro with kernel 5.3.12) fstab UUID=a49494f2-35a4-4a9c-aab0-1afc905c02c2 /mnt/test btrfs defaults 0 2 dmesg [675174.887900] BTRFS error (device sde1): bdev /dev/sde1 errs: wr 0, rd 0, flush 0, corrupt 2137, gen 0 [102857.086874] BTRFS warning (device sdc1): csum failed root 256 ino 260 off 1735843840 csum 0xf69f8dd2 expected csum 0x96e71981 mirror 1
I made a mistake, directsync mode also corrupts data
Created attachment 286155 [details] signature.asc On Tue, Nov 26, 2019 at 09:24:48AM +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=205655 > > Bug ID: 205655 > Summary: kvm with cache=none and btrfs -> corrupted file system > Product: Virtualization > Version: unspecified > Kernel Version: 4.9 4.19 5.3.12 > Hardware: x86-64 > OS: Linux > Tree: Mainline > Status: NEW > Severity: high > Priority: P1 > Component: kvm > Assignee: virtualization_kvm@kernel-bugs.osdl.org > Reporter: denis.ovsyannikov@gmail.com > Regression: No > > hello > we use kvm with disks formatted in btrfs > when we turned on the mode "cache=none" > got data corruption > other modes work well > > we tested it on three servers and the result is always repeated > we tested on three operating systems(debian 9, debian 10, manjaro with kernel > 5.3.12) > > fstab > UUID=a49494f2-35a4-4a9c-aab0-1afc905c02c2 /mnt/test btrfs defaults 0 2 > > dmesg > [675174.887900] BTRFS error (device sde1): bdev /dev/sde1 errs: wr 0, rd 0, > flush 0, corrupt 2137, gen 0 > > [102857.086874] BTRFS warning (device sdc1): csum failed root 256 ino 260 off > 1735843840 csum 0xf69f8dd2 expected csum 0x96e71981 mirror 1 Please post your QEMU command-line. What is the storage configuration on the host? Which host file system are you using? Which image file format? What test is being run inside the guest? Is this a regression? Which host and guest kernel versions worked fine before?