On Thu, 2015-11-05 at 10:44 +0000, OmegaPhil wrote: > On 05/11/15 04:18, Duncan wrote: > > OmegaPhil posted on Wed, 04 Nov 2015 21:53:09 +0000 as excerpted: > > VM image files (and large database files, for the same reason) are > > a bit > > of a problem on btrfs, and indeed, any COW-based filesystem, since > > the > > random rewrite pattern matching that use-case is pretty much the > > absolute > > worst-case match for a COW-based filesystem there is. > > Since you're not doing snapshotting (which conflicts with this > > option, > > with an imperfect workaround), setting nocow on those files may > > well > > eliminate the problem, but be aware if you aren't already that (1) > > nocow > > does turn off checksumming as well, in ordered to avoid a race that > > could > > easily lead to data corruption, and (2) you can't just activate
> So a couple of gig still unaccountable but irrelevant. Thanks, > problem > solved! Although hopefully checksumming will be allowed on nocow > files > in the future as thats currently 17% of all data unprotected and will > get worse... There's actually an interesting workaround to this: Although the VM disk images aren't checksummed on the host filesystem, you can use btrfs *inside* the VMs and enable checksumming there. The downside is that you can only verify the VM data by booting the VM and running a scrub from inside. This of course doesn't help if your VMs are Windows or legacy versions of Linux without btrfs support. On BSD you could try ZFS. -- Calvin Walton <calvin.wal...@kepstin.ca> -- 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
