All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jim Salter <jim@jrs-s.net>
To: Chris Murphy <lists@colorremedies.com>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: VM nocow, should VM software set +C by default?
Date: Tue, 25 Feb 2014 12:53:28 -0500	[thread overview]
Message-ID: <530CD898.6090401@jrs-s.net> (raw)
In-Reply-To: <4C05BCCD-ED77-4D8D-B9C7-47CB6D1B4ACC@colorremedies.com>

Put me in on Team Justin on this particular issue.  I get and grant that 
in some use cases you might get pathological behavior out of DB or VM 
binaries which aren't set NODATACOW, but in my own use - including 
several near-terabyte-size VM images being used by ten+ people all day 
long for their primary work - I haven't personally observed any 
pathological behavior, and I *don't* have NODATACOW set.

I would prefer to have the benefits of COW being turned on unless and 
until I categorically NEED to disable it in order to avoid pathological 
performance issues.

Also note that ZFS doesn't even *have* a NODATACOW option, is generally 
less performant than btrfs in general in my experience, and yet I've 
been running 100-ish VMs - not toys, actual 
depended-on-by-lots-of-people-daily-workhorses - in .qcow2-on-ZFS format 
for years now without issue.

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.


On 02/25/2014 12:44 PM, Chris Murphy wrote:
> On Feb 25, 2014, at 2:16 AM, Justin Ossevoort <justin@internetionals.nl> wrote:
>
>> I think in principle: No.
>>
>> It is something that should be documented as advise in the VM software documentation. But things like storage management is the domain of the distribution or systems administrator.
> No, that's a recipe for users having a chaotic experience. Either the VM managing application needs to set +C on image files, or the file system needs to be optimized for this use case. Consider the Gnome Boxes user. They're not in a good position to do this themselves, and each distro doing this causes fragmented experience. It's better if the application developer (Gnome Boxes, VMM) or possibly libvirt to set +C on VM images; or as a general purpose file system for it to be optimized for this use case.
>
> Either way it leaves the end user out of what amounts to esoteric configuration.
>


  reply	other threads:[~2014-02-25 17:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-21 16:55 VM nocow, should VM software set +C by default? Chris Murphy
2014-02-21 17:56 ` Duncan
2014-02-25  9:16 ` Justin Ossevoort
2014-02-25 17:44   ` Chris Murphy
2014-02-25 17:53     ` Jim Salter [this message]
2014-02-25 18:33       ` Chris Murphy
2014-02-26  5:43         ` Duncan
2014-02-25 18:01     ` Roman Mamedov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=530CD898.6090401@jrs-s.net \
    --to=jim@jrs-s.net \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.