All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lars Ellenberg <lars.ellenberg@linbit.com>
To: drbd-dev@lists.linbit.com
Subject: Re: [Drbd-dev] Re: drbd in linux-ha cvs
Date: Tue, 7 Sep 2004 11:15:07 +0200	[thread overview]
Message-ID: <20040907091507.GA3257@nudl> (raw)
In-Reply-To: <200409070957.57371.philipp.reisner@linbit.com>

On Tue, Sep 07, 2004 at 09:57:57AM +0200, Philipp Reisner wrote:
> 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.

I don't want to make it easier to write generation counts.
heartbeat-TNG may have use for knowing the current ones, though.

> 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. ]

or only enabled with "verify config" or something like that.

> 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.

the point was to have an easy way to _read_ all available information in
a well defined way in one chunk. and having it in k=v form makes it
direktly useable by bash, and easily useable by perl:

  $_=`drbdadm info r0`; %drbdinfo = /^(.*?)=(.*?)$/mg; # :-)

I do NOT want to make it easy to _modify_ on-disk meta data.
if it is too easy (or even documented), people will screw up,
and blame us for it.

	lge

  reply	other threads:[~2004-09-07  9:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20040906135609.GT11820@marowsky-bree.de>
     [not found] ` <20040906145237.GB28956@nudl>
2004-09-07  7:57   ` [Drbd-dev] Re: drbd in linux-ha cvs Philipp Reisner
2004-09-07  9:15     ` Lars Ellenberg [this message]
2004-09-07  9:43       ` Philipp Reisner
2004-09-07 10:49         ` Lars Ellenberg
2004-09-07 12:03           ` Lars Marowsky-Bree
2004-09-07 12:56             ` Philipp Reisner
2004-09-07 15:45               ` Lars Ellenberg
2004-09-08 11:21               ` Lars Marowsky-Bree
2004-09-07 12:54           ` Philipp Reisner
2004-09-07  9:45       ` Philipp Reisner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040907091507.GA3257@nudl \
    --to=lars.ellenberg@linbit.com \
    --cc=drbd-dev@lists.linbit.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.