> On 28 Apr 2017, at 22:09, Chris Murphy <li...@colorremedies.com> wrote: > > On Fri, Apr 28, 2017 at 3:10 AM, Christophe de Dinechin > <dinec...@redhat.com> wrote: > >> >> QEMU qcow2. Host is BTRFS. Guests are BTRFS, LVM, Ext4, NTFS (winXP and >> win10) and HFS+ (macOS Sierra). I think I had 7 VMs installed, planned to >> restore another 8 from backups before my previous disk crash. I usually have >> at least 2 running, often as many as 5 (fedora, ubuntu, winXP, win10, macOS) >> to cover my software testing needs. > > That is quite a torture test for any file system but more so Btrfs.
Sorry, but could you elaborate why it’s worse for btrfs? > How are the qcow2 files being created? In most cases, default qcow2 configuration as given by virt-manager. > What's the qemu-img create > command? In particular i'm wondering if these qcow2 files are cow or > nocow; if they're compressed by Btrfs; and how many fragments they > have with filefrag. I suspect they are cow. I’ll check (on the other machine with a similar setup) when I’m back home. > > When I was using qcow2 for backing I used > > qemu-img create -f qcow2 -o preallocation=falloc,nocow=on,lazy_refcounts=on > > But then later I started using fallocated raw files with chattr +C > applied. And these days I'm just using LVM thin volumes. The journaled > file systems in a guest cause a ton of backing file fragmentation > unless nocow is used on Btrfs. I've seen hundreds of thousands of > extents for a single backing file for a Windows guest. Are there btrfs commands I could run on a read-only filesystem that would give me this information? Thanks Christophe > > -- > Chris Murphy > -- > 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 -- 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