From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mescal.linbit (213-229-1-138.sdsl-line.inode.at [213.229.1.138]) by mail.linbit.com (LINBIT Mail Daemon) with ESMTP id 237EF142F3 for ; Tue, 7 Sep 2004 09:58:01 +0200 (CEST) From: Philipp Reisner To: drbd-dev@lists.linbit.com Date: Tue, 7 Sep 2004 09:57:57 +0200 References: <20040906135609.GT11820@marowsky-bree.de> <20040906145237.GB28956@nudl> In-Reply-To: <20040906145237.GB28956@nudl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200409070957.57371.philipp.reisner@linbit.com> Subject: [Drbd-dev] Re: drbd in linux-ha cvs List-Id: Coordination of development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Monday 06 September 2004 16:52, you wrote: > waere es sinnvoll sowas zu haben: > > drbdadm dump_meta_data r0 (oder info oder wie immer wir das nennen wollen) > > output would be bash sourceable: > GEN_COUNT=SOME:LONGER:STRING:WITH:NUMBERS:AND:STUFF > LOCAL_STATE={Primary,Secondary} > REMOTE_STATE=... > CSTATE=... > LOCAL_STORAGE=... > > > name space clashes können so gelöst werden: > eval `drbdadm info r0 | sed 's/^/DRBD_/'` > > müsste einmal vernünftig überlegt werden, welche informationen wir > exportieren wollen, und wie die variablen genannt werden. > wie drbdadm an die info rankommt ist seine sache. > > deal? > Of course I am open to this idea. Ideas: 1) We move the read_gc.pl/write_gc.pl to the user directory. 2) Make them to one C program: drbdmeta -> in the future the module never creates the meta data block. One can use drbdmeta to create, read and modify the drbdmeta block. drbdmeta refuses to write to it as long as the module is loaded (configured). 3) drbdadm is the nice frontend to drbdmeta is it is to drbdsetup. Currently we have these drbdadm commands that are not displayed at the usage output: { "sh-resources", sh_resources,0 ,0,0 }, { "sh-mod-parms", sh_mod_parms,0 ,0,0 }, { "sh-dev", sh_dev, 0 ,0,1 }, { "sh-ll-dev", sh_ll_dev, 0 ,0,1 }, { "sh-md-dev", sh_md_dev, 0 ,0,1 }, { "sh-md-idx", sh_md_idx, 0 ,0,1 } ... and we have state and cstate: { "state", adm_generic_s,"state" ,1,1 }, { "cstate", adm_generic_s,"cstate" ,1,1 }, with the current interface you would do: CSTATE=$(drbdadm cstate r0) LOCAL_STATE=$( $DRBDADM state $RES 2> /dev/null ) LOCAL_STATE=${LOCAL_STATE%/*} LOCAL_STORAGE= $(drbdadm sh-ll-dev r0) ... With the current interface we have a lot of calls to drbdadm, so lets have a look at the performance: root@bloody:~/drbd07/user# time drbdadm sh-ll-dev r0 /dev/hdc1 real 0m0.170s user 0m0.059s sys 0m0.111s ... Quite slow! So I disabled "verify_ips()". [ should probabely be really disabled. ] root@bloody:~/drbd07/user# time ./drbdadm sh-ll-dev r0 /dev/hdc1 real 0m0.006s user 0m0.001s sys 0m0.005s ... now a call to drbdadm is as cheap as expected. So with continuing the current way of doing things, I would extend the interface in this way: drbdadm md-set-gc 1:2:3:4:5:6 r0 drbdadm md-get-gc 1:2:3:4:5:6 r0 drbdadm md-get/set-{la-size|consistent|etc...} resources.... drbdadm md-create r0 I rather prefer the current way, since it is also language agnostic. In perl: $local_storage = `drbdadm sh-ll-dev r0`; While the proposed interface is tied to bash. -philipp -- : Dipl-Ing Philipp Reisner Tel +43-1-8178292-50 : : LINBIT Information Technologies GmbH Fax +43-1-8178292-82 : : Schönbrunnerstr 244, 1120 Vienna, Austria http://www.linbit.com :