2017-09-12 11:02 GMT+03:00 Marat Khalili <m...@rqc.ru>: > Thanks to the help from the list I've successfully replaced part of btrfs > raid1 filesystem. However, while I waited for best opinions on the course of > actions, the root filesystem of one the qemu-kvm VMs went read-only, and > this root was of course based in a qcow2 file on the problematic btrfs (the > root filesystem of the VM itself is ext4, not btrfs). It is very well > possible that it is a coincidence or something inducted by heavier than > usual IO load, but it is hard for me to ignore the possibility that somehow > the hardware error was propagated to VM. Is it possible? > > No other processes on the machine developed any problems, but: > (1) it is very well possible that problematic sector belonged to this qcow2 > file; > (2) it is a Kernel VM after all, and it might bypass normal IO paths of > userspace processes; > (3) it is possible that it uses O_DIRECT or something, and btrfs raid1 does > not fully protect this kind of access. > Does this make any sense? > > I could not login to the VM normally to see logs, and made big mistake of > rebooting it. Now all I see in its logs is big hole, since, well, it went > read-only :( I'll try to find out if (1) above is true after I finish > migrating data from HDD and remove the it. I wonder where else can I look? > > -- > > With Best Regards, > Marat Khalili
AFAIK, if while read BTRFS get Read Error in RAID1, application will also see that error and if application can't handle it -> you got a problems So Btrfs RAID1 ONLY protect data, not application (qemu in your case). -- Have a nice day, Timofey. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
