From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37341) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uwvdc-0005Nz-4l for qemu-devel@nongnu.org; Wed, 10 Jul 2013 10:45:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UwvdV-0007Jo-0U for qemu-devel@nongnu.org; Wed, 10 Jul 2013 10:45:00 -0400 Received: from e28smtp09.in.ibm.com ([122.248.162.9]:52256) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UwvdU-0007J2-Fm for qemu-devel@nongnu.org; Wed, 10 Jul 2013 10:44:52 -0400 Received: from /spool/local by e28smtp09.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 10 Jul 2013 20:09:50 +0530 Received: from d28relay03.in.ibm.com (d28relay03.in.ibm.com [9.184.220.60]) by d28dlp01.in.ibm.com (Postfix) with ESMTP id 15E5BE0056 for ; Wed, 10 Jul 2013 20:14:33 +0530 (IST) Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r6AEjKnn32964742 for ; Wed, 10 Jul 2013 20:15:20 +0530 Received: from d28av04.in.ibm.com (loopback [127.0.0.1]) by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r6AEijtP013542 for ; Thu, 11 Jul 2013 00:44:45 +1000 Message-ID: <51DD731D.5040108@linux.vnet.ibm.com> Date: Wed, 10 Jul 2013 22:43:41 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <1373270451-18436-1-git-send-email-xiawenc@linux.vnet.ibm.com> <1373270451-18436-3-git-send-email-xiawenc@linux.vnet.ibm.com> <20130710131040.GO3898@dhcp-200-207.str.redhat.com> <51DD67A2.6090806@linux.vnet.ibm.com> <20130710142257.GP3898@dhcp-200-207.str.redhat.com> In-Reply-To: <20130710142257.GP3898@dhcp-200-207.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH V4 2/9] snapshot: add paired functions for internal snapshot id and name List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: phrdina@redhat.com, famz@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org, lcapitulino@redhat.com, stefanha@redhat.com, pbonzini@redhat.com, dietmar@proxmox.com 于 2013-7-10 22:22, Kevin Wolf 写道: > Am 10.07.2013 um 15:54 hat Wenchao Xia geschrieben: >> 于 2013-7-10 21:10, Kevin Wolf 写道: >>> Am 08.07.2013 um 10:00 hat Wenchao Xia geschrieben: >>>> Internal snapshot's ID and name concept are both visible in general >>>> block level, they are observed by user in "info snapshots", so it is >>>> possible to have conflict. Although we can separate the two concept in >>>> programming, but if they can be distinguished in string itself, things >>>> will be simple and clear, so introduce two functions to do it. >>>> >>>> The implemention, qcow2 snapshot calls snapshot_id_string_generate() to >>>> make sure it follows the rule in driver. If caller or user give a check >>>> with snapshot_name_wellformed() before create snapshot, then the ID >>>> and name will never conflict. The check can be also taken in >>>> qcow2_snapshot_create(), but require it to return error reason. >>> >>> I'm not sure how useful this is. While we can restrict what IDs we allow >>> for creating new snapshots, we cannot take any advantage from it because >>> existing snapshots could already be named with only digits (they could >>> also use a non-numeric ID). At the end of the day we're limiting the >> Qcow2's ID seems always numeric, do you mean sheepdog may have >> non-numeric ID? > > That's not true, qcow2 has an ID string rather than a numeric ID. > But there is no way to specify non-numeric ID in public interface, such as savevm, qemu-img, and in qcow2_snapshot_create(), find_new_snapshot_id() will always fill in a numeric ID string, so result is that, qcow2's snapshot ID string is always a numeric string. >>> choice of IDs that can be generated with the QMP command without a real >>> reason. >>> >> This patch may limit the choice of snapshot name. Maybe we can't >> benefit from it now because existing code, but shouldn't it be improved >> in any new interface to alleviate the problem? I guess you idea >> is drop this check in the new interface, isn't it? > > Well, the thought is that limiting it in QMP is of no use if there is no > corresponding limitation in the backend. So yes, I think, as long as > block drivers can deal with numeric snapshots names, QMP should allow > dealing with them. > OK, I'll drop this limit. > Kevin > -- Best Regards Wenchao Xia