On Feb 25, 2014, at 10:53 AM, Jim Salter <j...@jrs-s.net> wrote: > IME, IMO, the potential performance problems with COW and db/vm do /exist/ > but they're way, WAY overstated, and unlikely to rear their heads at all in > the majority of use-cases.
Right. Unfortunately I'm only aware of such anecdotes, including my own, that performance is OK or not OK. The specifics of the configuration need to be described. So what information do we need to ask users who are having such problems, before we ask them to use +C? On Feb 25, 2014, at 11:01 AM, Roman Mamedov <r...@romanrm.net> wrote: > Insisting that every program now has to include a workaround for a > filesystem-specific gimmick does not seem to be a nice design decision > long-term. I have tepid agreement that +C is a short term work around, and ideally neither application developers nor users would need to do anything special to use VM images on Btrfs. But in that case I'd still like to better understand what configurations are causing real performance problems to occur for some people when they don't use +C. Is this simply needing to implement a better or best practice rather than use of +C? So I guess more configuration information is needed to see what combination of attributes is inducing these reported problems. I've had a qcow2 image with more than 30,000 extents and didn't notice a performance drop. So I don't know that number of extents is the problem. Maybe it's how they're arranged on disk and what's causing the problem is excessive seeking on HDD? Or does this problem sometimes also still happen on SSD? Chris Murphy-- 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
