P. Remek <p.remek1@xxxxxxxxxxxxxx> schrieb: >> Yes, it was implemented for the purpose of allowing an application to >> implement its own caching - probably for the sole purpose of doing it >> "better" or more efficient. But it simply does not work out that well, at >> least with COW fs. The original idea "performance" is more or less eaten >> away in a COW scenario - or worse. And that in turn is why Linus said >> O_DIRECT is broken and should go away, use cache hinting instead. > > Linus is saying to use things like madvise but the fact is that in > reality people are using O_DIRECT instead of it, so it is important to > get it right. Yeah, quite true - apparently... But as you already found, the O_DIRECT implementation of btrfs is probably not the culprit. > The case which I am interested is KVM. Virtual machine > disk file is opened with O_DIRECT so that when Virtual machine is > doing IO, it is not cached twice - first time on guest operating > system level, and second time on hypervisor host operating system > level. With O_DIRECT it is only cached in guest. In VirtualBox I enabled host-side caching on purpose and instead lowered the RAM. I don't know if VirtualBox does something like memory ballooning, but usually I'd expect ballooning to push cache out of RAM - so host-side caching may make sense. I never measured it but it feels a bit snappier to work inside the VirtualBox machine. Of course, recommendation depends on if you are using ballooning and VM density. In VirtualBox, this setting probably just turns off O_DIRECT. And my VM images are set to nocow. -- Replies to list only preferred. -- 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
