From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44433) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anXrc-0003jH-87 for qemu-devel@nongnu.org; Tue, 05 Apr 2016 16:46:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1anXrX-0002yp-5R for qemu-devel@nongnu.org; Tue, 05 Apr 2016 16:46:16 -0400 Received: from barbershop.grep.be ([89.106.240.122]:40677) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anXrW-0002yb-VV for qemu-devel@nongnu.org; Tue, 05 Apr 2016 16:46:11 -0400 Date: Tue, 5 Apr 2016 22:45:48 +0200 From: Wouter Verhelst Message-ID: <20160405204548.GB13913@grep.be> References: <1459779314-12266-1-git-send-email-eblake@redhat.com> <1459808143-22482-1-git-send-email-eblake@redhat.com> <4138293.p7OeGaqt34@adelgunde> <5703EB22.5010507@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5703EB22.5010507@redhat.com> Subject: Re: [Qemu-devel] [Nbd] [PATCH v2] doc: Allow NBD_CMD_FLAG_NO_HOLE during NBD_CMD_WRITE List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Markus Pargmann , nbd-general@lists.sourceforge.net, pborzenkov@virtuozzo.com, qemu-devel@nongnu.org, den@openvz.org On Tue, Apr 05, 2016 at 10:43:14AM -0600, Eric Blake wrote: > On 04/05/2016 03:38 AM, Markus Pargmann wrote: > > Hi, > > > > On Monday 04 April 2016 16:15:43 Eric Blake wrote: > >> qemu already has an existing server implementation option that will > >> explicitly search the payload of NBD_CMD_WRITE for large blocks of > >> zeroes, and punch holes in the underlying file. For old clients > >> that don't know how to use the new NBD_CMD_WRITE_ZEROES, this is a > >> workaround to keep the server's destination file approximately as > >> sparse as the client's source. However, for new clients that know > >> how to explicitly request holes, it is unnecessary overhead; and > >> can lead to the server punching a hole and risking fragmentation or > >> future ENOSPC even when the client explicitly wanted to write > >> zeroes rather than a hole. So it makes sense to let the new > >> NBD_CMD_FLAG_NO_HOLE work for WRITE as well as WRITE_ZEROES. > > > > From the commit message it sounds like this is only for new clients > > supporting WRITE_ZEROES because for those we don't want to search > > through all the data of normal WRITEs. If you don't need to set this for > > each WRITE individually perhaps we could move it to the negotiation > > part? > > Interesting idea. So we'd add a new NBD_OPT_XXX that lets the server > know that "I plan on using WRITE_ZEROS and TRIM as the only places where > I want you to trim, so you can avoid scanning for zeroes in WRITE"; the > server replies with NBD_REP_ACK if it understands the client (in which > case the server _should_ be advertising NBD_FLAG_SEND_WRITE_ZEROES > and/or NBD_FLAG_SEND_TRIM), and with NBD_REP_ERR_UNSUP if it is too old > (the server may still advertise TRIM, but probably should not advertise > WRITE_ZEROES - we are still early enough that we could mandate that any > server that supports WRITE_ZEROES also supports the new NBD_OPT_XXX). Certainly. However, I think a server should be allowed to reply to this NBD_OPT_NO_AUTO_HOLE (or whatever we end up calling it) with NBD_REP_ERR_POLICY -- i.e., it understands the request, but server-side configuration forbids it to heed it. This kind of stuff is *always* a trade-off. Someone low on diskspace might want to force their server to scan for zeroes, in the understanding that things might break. [...] > Does the idea of a new NBD_OPT_ make enough sense to write that up > rather than mandating the use of NBD_CMD_FLAG_NO_HOLE with WRITE? Yeah, it does to me. The client shouldn't have to care much about this kind of stuff. -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12