From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47521) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1albl0-0006Dg-Je for qemu-devel@nongnu.org; Thu, 31 Mar 2016 08:31:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1albkw-0005FD-FR for qemu-devel@nongnu.org; Thu, 31 Mar 2016 08:31:26 -0400 Date: Thu, 31 Mar 2016 13:31:05 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20160331123105.GK2265@work-vm> References: <56EA7C62.3090000@cn.fujitsu.com> <20160317094831.GA2504@work-vm> <56EA7F39.9060504@cn.fujitsu.com> <56FAA168.9090304@redhat.com> <56FAA2C4.3000002@redhat.com> <56FAA47A.2020801@redhat.com> <56FBEBA3.9070305@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v12 2/3] quorum: implement bdrv_add_child() and bdrv_del_child() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alberto Garcia Cc: Kevin Wolf , Changlong Xie , qemu block , Markus Armbruster , Jiang Yunhong , Dong Eddie , qemu devel , Max Reitz , Gonglei , Stefan Hajnoczi , zhanghailiang * Alberto Garcia (berto@igalia.com) wrote: > On Wed 30 Mar 2016 05:07:15 PM CEST, Max Reitz wrote: > >> I also have another (not directly related) question: why not simply > >> use the node name when removing children? I understood that the idea > >> was that it's possible to have the same node attached twice to the > >> same Quorum, but can you actually do that? And what's the use case? > > > > What I like about using the child role name is that it automatically > > prevents you from specifying a node that is not a child of the given > > parent. > > Right, but checking if a node is not a child and returning an error is > very simple. And it doesn't require the user to keep track of the node > name *and* the child role name. > > Unless I'm forgetting something this would be the first time we expose > the child role name in the API, that's why I'm wondering if it's > something worth doing. > > > Which makes me notice that it might be a good idea to require the user > > to specify the child's role when adding a new child. In this version > > of this series (where only quorum is supported), the children are just > > inserted in numerical order (first free slot is taken first), but > > maybe the user wants to insert them in a different order. > > For the Quorum case it totally makes sense to let the user choose the > position of the new child. > > But for creating a Quorum array in the first place we don't require > that, the order is the one that the user provides, and the user does not > need to know about the child role names at that point. Actually in my setup I only add the local block device using the normal command line, and use drive_add even at startup. It solves a lot of the ordering problems with getting COLO booted. Dave > > > And the "filling up quorum's children" topic then makes me notice that > > (x-)blockdev-change should probably be transaction-able (so you can > > restructure the whole BDS graph in a single transaction), but that's > > something we can care about later on. > > I agree. > > Berto -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK