On 06/15/2018 08:10 PM, Austin S. Hemmelgarn wrote: > On 2018-06-15 13:40, Chris Murphy wrote: >> On Fri, Jun 15, 2018 at 5:33 AM, ein <[email protected]> wrote: >>> Hello group, >>> >>> does anyone have had any luck with hosting qemu kvm images resided on BTRFS >>> filesystem while serving >>> the volume via iSCSI? >>> >>> I encouraged some unidentified problem and I am able to replicate it. >>> Basically the NTFS filesystem >>> inside RAW image gets corrupted every time when Windows guest boots. What >>> is weired is that changing >>> filesystem for ext4 or xfs solves the issue. >>> >>> The problem replication looks as follows: >>> 1) run chkdsk on the guest to make sure the filesystem structure is in good >>> shape, >>> 2) shut down the VM via libvirtd, >>> 3) rsync changes between source and backup image, >>> 4) generate SHA1 for backup and original and compare it, >>> 5) try to run guest on the backup image, I was able to boot windows once >>> for ten times, every time >>> after reboot NTFS' chkdsk finds problems with filesystem and the VM is >>> unable to boot again. >>> >>> What am I missing? >>> >>> VM disk config: >>> >>> <disk type='file' device='disk'> >>> <driver name='qemu' type='raw' cache='none' io='native'/> >> >> >> >> cache=none uses O_DIRECT, and that's the source of the issue with VM >> images on Btrfs. Details are in the list archive. >> >> I'm not really sure what you want to use with Windows in this >> particular case, probably not cache=unsafe though. I'd say give >> writethrough a shot and see how it affects performance and fixes this >> problem. >> > cache=writethrough is probably going to be the best option, unless you want > to switch to > cache=writeback and disable write caching in Windows (which from what I hear > can actually give > better performance than using cache=none).
Thank you to each and everyone of you, I'll give it a shot. Performance is not a problem, recovery purposes only, I'd like to run the VM once to dump some configuration data. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
