From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37081) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UnVUH-00078w-OV for qemu-devel@nongnu.org; Fri, 14 Jun 2013 11:00:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UnVUG-0000lh-KF for qemu-devel@nongnu.org; Fri, 14 Jun 2013 11:00:25 -0400 Received: from mail-qe0-f52.google.com ([209.85.128.52]:49849) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UnVUG-0000lW-Gf for qemu-devel@nongnu.org; Fri, 14 Jun 2013 11:00:24 -0400 Received: by mail-qe0-f52.google.com with SMTP id i11so367255qej.25 for ; Fri, 14 Jun 2013 08:00:24 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <51BB3002.9090801@redhat.com> Date: Fri, 14 Jun 2013 11:00:18 -0400 From: Paolo Bonzini MIME-Version: 1.0 References: <1371124063-12971-1-git-send-email-kwolf@redhat.com> <1371124063-12971-4-git-send-email-kwolf@redhat.com> <51BA4344.7070608@redhat.com> <20130614083110.GB2389@dhcp-200-207.str.redhat.com> <51BB25C3.4000904@redhat.com> <20130614143147.GD2389@dhcp-200-207.str.redhat.com> In-Reply-To: <20130614143147.GD2389@dhcp-200-207.str.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/5] qcow2: Options to enable discard for freed clusters List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org, stefanha@redhat.com Il 14/06/2013 10:31, Kevin Wolf ha scritto: >> It looks like QCOW2_OPT_DISCARD_OTHER is a rare case, so I don't mind >> leaving it as default to false. It won't waste more than a few clusters. > > Yes, it's generally relatively rare, like growing L1 or refcount table. > There is one case where it should trigger a lot, though: Overwriting > clusters of a compressed image. > > Hm, though actually it doesn't make a lot of sense there. The freed > cluster will immediately be used by the next write. Maybe COW should > actually be QCOW2_OPT_DISCARD_NEVER... Sounds reasonable. >> In the end discard_snapshot and discard_other should rarely be needed in >> practice, so I don't think having discard=... is a mistake. Too many >> knobs won't really be needed. >> >> In fact, perhaps we do not need discard_snapshot and discard_request, >> only discard_other. discard_snapshot can be replaced by >> file.discard=ignore, discard_request by discard=unmap. > > This is only true if you rule out some combination as useless. For > example you would say that if you want to process guest requests, you > always want to have snapshots discarded as well. You also assume that > nobody wants the current behaviour (free clusters in qcow2 metadata, but > don't send discards to raw-posix). > > Isn't this assuming a bit too much? > > To be clear, I don't expect these knobs to be used much either, but I > have some feeling that some people (including us while debugging or > asking questions) may be glad later to have such low-level options that > control each layer separately. Yeah, you're right. They're definitely useful to have, even if it is "just in case". Paolo