On Jan 4, 2014, at 11:39 PM, Marc MERLIN <marc@xxxxxxxxxxx> wrote: > > Nope, I never posted anything until now. Hopefully you agree that it's > not ok for btrfs/kernel to just kill my system for over 2H until I power > it off before of defragging one file. I did hit a severe performance but > if it's not a never ending loop. > > gandalfthegreat:/var/local/nobck/VirtualBox VMs/Win7# filefrag Win7.vdi > Win7.vdi: 156222 extents found > > Considering how virtualbox works, that's hardly surprising. I haven't read anything so far indicating defrag applies to the VM container use case, rather nodatacow via xattr +C is the way to go. At least for now. > > But doesn't it make sense to see why the kernel is near deadlocking on a > single file defrag first? It's better than a panic or corrupt data. So far the best combination I've found, open to other suggestions though, is +C xattr on /var/lib/libvirt/images, creating non-preallocated qcow2 files, and snapshotting the qcow2 file with qemu-img. Granted when sysroot is snapshot, I'm making btrfs snapshots of these qcow2 files. Another option is to make /var/lib/libvirt/images a subvolume, and then when sysroot is snapshot, then /var/lib/libvirt/images is immune to being snapshot automatically with the parent subvolume. I'd have to explicitly snapshot it. This may be a better way to go to avoid accumulation of btrfs snapshots of qcow2 snapshot files. This may already be a known problem but it's worth sysrq+w, and then dmesg and posting those results if you haven't already. 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
