On 7/8/13 8:14 AM, David Sterba wrote:
On Thu, Jul 04, 2013 at 06:26:32PM +0100, Graham Anderson wrote:
On Thursday 04 Jul 2013 11:54:05 Jeff Mahoney wrote:
So, I'd like to hear your stories. What's worked for you? What hasn't worked? What would you consider the pain points with using btrfs?
When I tested a variety of KVM image formats and settings to see what worked well with regards to disk read/write speed; I found that any disk image stored on a btrfs volume made writing to the the VM filesystem (ext4) too slow to be usable for any kind of real work load.
VM and database loads do not play well with the COW mechanism. The NOCOW file attribute (chattr +C) fixed the performance problems with VM images for me and reportedly for others. This comes at a price, the checksums are turned off for the file.
For database workloads, that's typically no price. That's removing unnecessary redundancy. The bigger DB workloads just want to use the FS as a way to have names map to blocks on disk and would otherwise be happy to have the FS keep out of the way. They usually don't even want the page cache involved. For VM images, I'd argue it may be more appropriate to have the integrity checking inside the VM itself anyway. ext4 can do this now, at least in the journal, as can btrfs. I can't comment on Windows VMs, of course. -Jeff -- Jeff Mahoney SUSE Labs