I created two pools, one xfs one btrfs, default formatting and mount options. I then created a qcow2 file on each using virt-manager, also using default options. And default caching (whatever that is, I think it's writethrough but don't hold me to it). I then installed Windows 7 (not concurrently) to each qcow2 file. Immediately after install, at the BIOS screen for the 1st reboot from install, the fragment count is: btrfs: 1576 xfs: 665 After letting each of them proceed through their subsequent reboots, and hang out for ~ 1 hour while mscorsvw.exe and svchost.exe do a bunch of stuff busying up the drive and sucking CPU, I get the following counts once they went idle: btrfs 8042 xfs 8369 As a note, there was about 20-30 minutes of idle time at which point for xfs the extent count was 2564, and within 5 minutes of svchost.exe going all chaotic the fragment count was 8369. At which point it stayed there for another 10 or so minutes, and even through a couple reboots it stayed at that point. So there are Windows 7 processes that can cause a lot of fragmentation of qcow2 files in a very short period of time. I have no idea what they're doing, but a lot of this is probably just the nature of qcow2 files. Also, 'qemu-img create' has a relatively new option 'nocow'. If -o nocow=on then qemu-img sets xattr +C on the qcow2 file at the time of its creation. This is a btrfs only option, and is described in the man page. Does anyone know if filefrag's physical_offset value has any correlation to disk sectors at all? Or is it just another kind of logical value? I ask because the vast majority of the extents have sequential ordering based on the reported physical_offset. It's not like the extents are being created haphazardly all over the drive. So I'm not convinced that this kind of fragmentation is really a big problem. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
