From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40168) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cZBsf-000707-BA for qemu-devel@nongnu.org; Thu, 02 Feb 2017 02:32:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cZBse-0006aD-FS for qemu-devel@nongnu.org; Thu, 02 Feb 2017 02:32:33 -0500 From: Markus Armbruster References: <20170126110435.2777-1-berrange@redhat.com> <20170126110435.2777-4-berrange@redhat.com> <20170126123530.GB23095@lemon.Home> <20170126132708.GB29127@redhat.com> <6a9aeec8-d4ee-a0aa-7e04-0ee4295fef80@redhat.com> <8a13c995-c094-2704-c770-214132b2d6cf@redhat.com> <20170201121658.GF3232@redhat.com> <20170201122854.GG3232@redhat.com> <37f445c0-c174-bca4-7073-7aa6c64046b0@redhat.com> Date: Thu, 02 Feb 2017 08:32:23 +0100 In-Reply-To: <37f445c0-c174-bca4-7073-7aa6c64046b0@redhat.com> (Max Reitz's message of "Wed, 1 Feb 2017 13:31:01 +0100") Message-ID: <87bmul9hfc.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v1 3/6] qemu-img: add support for -n arg to dd command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: "Daniel P. Berrange" , Kevin Wolf , Fam Zheng , qemu-devel@nongnu.org, qemu-block@nongnu.org Max Reitz writes: > On 01.02.2017 13:28, Daniel P. Berrange wrote: >> On Wed, Feb 01, 2017 at 01:23:54PM +0100, Max Reitz wrote: >>> On 01.02.2017 13:16, Daniel P. Berrange wrote: >>>> On Wed, Feb 01, 2017 at 01:13:39PM +0100, Max Reitz wrote: >>>>> On 30.01.2017 19:37, Eric Blake wrote: >>>>>> On 01/26/2017 07:27 AM, Daniel P. Berrange wrote: >>>>>>> On Thu, Jan 26, 2017 at 08:35:30PM +0800, Fam Zheng wrote: >>>>>>>> On Thu, 01/26 11:04, Daniel P. Berrange wrote: >>>>>>>>> The -n arg to the convert command allows use of a pre-existing image, >>>>>>>>> rather than creating a new image. This adds a -n arg to the dd command >>>>>>>>> to get feature parity. >>>>>>>> >>>>>>>> I remember there was a discussion about changing qemu-img dd's default to a >>>>>>>> "conv=nocreat" semantic, if so, "-n" might not be that useful. But that part >>>>>>>> hasn't made it into the tree, and I'm not sure which direction we should take. >>>>>>>> (Personally I think default to nocreat is a good idea). >>>>>>> >>>>>>> Use nocreat by default would be semantically different from real "dd" >>>>>>> binary which feels undesirable if the goal is to make "qemu-img dd" >>>>>>> be as consistent with "dd" as possible. >>>>>>> >>>>>>> It would be trivial to rewrite this patch to add support for the "conv" >>>>>>> option, allowing the user to explicitly give 'qemu-img dd conv=nocreat' >>>>>>> instead of my 'qemu-img dd -n' syntax, without changing default semantics. >>>>>> >>>>>> Adding 'conv=nocreat' (and not '-n') feels like the right way to me. >>>>> >>>>> The original idea was to make conv=nocreat a mandatory option, I think. >>>>> qemu-img was supposed error out if the user did not specify it. >>>> >>>> I'm not really seeing a benefit in doing that - it would just break >>>> existing usage of qemu-img dd for no obvious benefit. >>> >>> Well... Is there existing usage? >> >> It shipped in 2.8.0 though, so imho that means we have to assume there >> are users, and thus additions must to be backwards compatible from now >> on. > > Depends. I don't think there are too many users, so we could still > justify a change if there's a very good reason for it. > > I do agree that it's probably not a very good reason, though. > >>> The benefit would be that one could (should?) expect qemu-img dd to >>> behave on disk images as if they were block devices; and dd to a block >>> device will not truncate or "recreate" it. >>> >>> If you don't give nocreat, it's thus a bit unclear whether you want to >>> delete and recreate the target or whether you want to write into it. >>> Some may expect qemu-img dd to behave as if the target is a normal file >>> (delete and recreate it), others may expect it's treated like a block >>> device (just write into it). If you force the user to specify nocreat, >>> it would make the behavior clear. >>> >>> (And you can always delete+recreate the target with qemu-img create.) >>> >>> It's all a bit complicated. :-/ >> >> If the goal is to be compatible with /usr/bin/dd then IIUC, the behaviour >> needs to be >> >> - If target is a block device, then silently assume nocreat|notrunc >> is set, even if not specified by user >> >> - If target is a file, then silently create & truncate the file >> unless nocreat or notrunc are set > > Yes. But you could easily argue that every image file is a "block device". No. /bin/dd treats exactly block special files as block special files, so the qemu-img command that tries to behave like it should do, too. In case you say that's inconvenient: pretty much everything about dd's archaic user interface is inconvenient. If you want convenient, roll your own. If you want familiar, stick to the original.