[Drbd-dev] Re: [john.cagle@hp.com: FW: device number request for drbd]

[Drbd-dev] Re: [john.cagle@hp.com: FW: device number request for drbd]

[Philipp Reisner]

On Wednesday 28 July 2004 10:06, Torben Mathiasen wrote:
> Hi,
>
> Sorry for the delay. We are moving to a new lanana maintainer (me).
>
> Regarding your Major number. You will receive block major 147. How do you
> want to minors named? /dev/drbd0, /dev/drbd1, ok?
>

/dev/drbd0, /dev/drbd1... are fine

Thanks,
-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 :

Re: [Drbd-dev] Re: [john.cagle@hp.com: FW: device number request for drbd]

[Lars Ellenberg]

/ 2004-07-28 12:10:14 +0200
\ Philipp Reisner:
> On Wednesday 28 July 2004 10:06, Torben Mathiasen wrote:
> > Hi,
> >
> > Sorry for the delay. We are moving to a new lanana maintainer (me).
> >
> > Regarding your Major number. You will receive block major 147. How do you
> > want to minors named? /dev/drbd0, /dev/drbd1, ok?
> >
> 
> /dev/drbd0, /dev/drbd1... are fine

great.

so, do we include that right away?
i.e. remove CONFIG_DRBD_MAJOR and module param major_nr again,
and make it fixed on 147 ?

or just "default" to 147 for now?

	lge

Re: [Drbd-dev] Re: [john.cagle@hp.com: FW: device number request for drbd]

[Philipp Reisner]

On Wednesday 28 July 2004 12:58, Lars Ellenberg wrote:
> / 2004-07-28 12:10:14 +0200
>
> \ Philipp Reisner:
> > On Wednesday 28 July 2004 10:06, Torben Mathiasen wrote:
> > > Hi,
> > >
> > > Sorry for the delay. We are moving to a new lanana maintainer (me).
> > >
> > > Regarding your Major number. You will receive block major 147. How do
> > > you want to minors named? /dev/drbd0, /dev/drbd1, ok?
> >
> > /dev/drbd0, /dev/drbd1... are fine
>
> great.
>
> so, do we include that right away?
> i.e. remove CONFIG_DRBD_MAJOR and module param major_nr again,
> and make it fixed on 147 ?
>
> or just "default" to 147 for now?
>

Yes I think so. The users should move to 147 with 0.7.1. 
Do you like to do the removal of module param ?

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

Re: [Drbd-dev] Re: [john.cagle@hp.com: FW: device number request for drbd]

[Lars Ellenberg]

/ 2004-07-28 14:08:00 +0200
\ Philipp Reisner:
> On Wednesday 28 July 2004 12:58, Lars Ellenberg wrote:
> > / 2004-07-28 12:10:14 +0200
> >
> > \ Philipp Reisner:
> > > On Wednesday 28 July 2004 10:06, Torben Mathiasen wrote:
> > > > Hi,
> > > >
> > > > Sorry for the delay. We are moving to a new lanana maintainer (me).
> > > >
> > > > Regarding your Major number. You will receive block major 147. How do
> > > > you want to minors named? /dev/drbd0, /dev/drbd1, ok?
> > >
> > > /dev/drbd0, /dev/drbd1... are fine
> >
> > great.
> >
> > so, do we include that right away?
> > i.e. remove CONFIG_DRBD_MAJOR and module param major_nr again,
> > and make it fixed on 147 ?
> >
> > or just "default" to 147 for now?
> >
> 
> Yes I think so. The users should move to 147 with 0.7.1. 
> Do you like to do the removal of module param ?

done in a minute...

I'll commit my change in receive_data_tail, too...
or is there still something special with the value of that NUMBER >= 24?

	Lars

Re: [Drbd-dev] Re: [john.cagle@hp.com: FW: device number request for drbd]

[Philipp Reisner]

> I'll commit my change in receive_data_tail, too...
> or is there still something special with the value of that NUMBER >= 24?

I think this derived from some number in Linux-2.2 :(

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

Re: [Drbd-dev] Re: [john.cagle@hp.com: FW: device number request for drbd]

[Lars Marowsky-Bree]

On 2004-07-28T14:08:00,
   Philipp Reisner <philipp.reisner@linbit.com> said:

> > or just "default" to 147 for now?
> >
> Yes I think so. The users should move to 147 with 0.7.1. 
> Do you like to do the removal of module param ?

You want to move the _device major_ within a stable series?!? I can see
the next local patch for SUSE coming right up ;-)


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering	    \ ever tried. ever failed. no matter.
SUSE Labs, Research and Development | try again. fail again. fail better.
SUSE LINUX AG - A Novell company    \ 	-- Samuel Beckett

Re: [Drbd-dev] Re: [john.cagle@hp.com: FW: device number request for drbd]

[Philipp Reisner]

[-- Attachment #1: Type: text/plain, Size: 817 bytes --]

On Wednesday 28 July 2004 16:12, Lars Marowsky-Bree wrote:
> On 2004-07-28T14:08:00,
>
>    Philipp Reisner <philipp.reisner@linbit.com> said:
> > > or just "default" to 147 for now?
> >
> > Yes I think so. The users should move to 147 with 0.7.1.
> > Do you like to do the removal of module param ?
>
> You want to move the _device major_ within a stable series?!? I can see
> the next local patch for SUSE coming right up ;-)
>

Yes I want to do this. Rolling upgrades are possible. 
I do not think that anybody actually cares about the major number 
or the name of the device node. 

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

[-- Attachment #2: upgrade_0.6.x_to_0.7.0.txt --]
[-- Type: text/plain, Size: 1418 bytes --]


DRBD upgrade instructions from 0.6.x to 0.7.0

* Since drbd-0.7.x is protocol incompatile to drbd-0.6.x you need
  to do a offline upgrade. I.e. no "rolling" upgrade possible.

  Make sure that the devices are in sync, make both sides secondary
  first and then stop DRBD on both nodes.

* In drbd-0.7.0 each DRBD resource needs 128MB of storage on
  some block device for its meta data. (With this /var/lib/drbd
  disappeared.)

  In order to do this upgrade you either need to

   A) shrink your filesystems on the DRBD devices by at least 128MB
   B) grow the backing_storage of the DRBD devices by at leas 128MB
   C) have one seperate block_device for all meta data

  A)
  ext2/ext3   resize2fs
  reiserfs    resize_reiserfs     
  xfs         xfsdump, xfsrestore ; xfs can only grow

  B)
  lvresize    in case you run DRBD on LVM
  (fdisk)     (Only do this if you know what you are doing.)

  C)
  The device needs to be n*128MB, where n is the number of 
  DRBD resources.

* Update you configurate file:
  - Change it to the new syntax.
  - Remove the disk-size parameter from you drbd.conf
  - Add the meta-disk settings
  - Remove tl-size
  - Change sync-min & sync-max to sync { rate }
  - Add the al-extents setting

* Start DRBD on both nodes

* Tune the al-extents setting to balance the number of updates
  to the metadata per minute (see cat /proc/drbd umber "al:") vs
  the expected resync time. 

[-- Attachment #3: upgrade_0.7.0_to_0.7.1.txt --]
[-- Type: text/plain, Size: 719 bytes --]


DRBD upgrade instructions from 0.7.0 to 0.7.1

With drbd-0.7.1 we have our own major number, and our own device
files. (=No longer misuse /dev/nbX)

* Start on the node, on which all devices are secondary.
* /etc/init.d/drbd stop
* Install drbd-0.7.1
* Run these commands as root:

sed -e "s/\/dev\/nb/\/dev\/drbd/" < /etc/drbd.conf > /etc/drbd.conf_new
mv /etc/drbd.conf /etc/drbd.conf_old ; mv /etc/drbd.conf_new /etc/drbd.conf
sed -e "s/\/dev\/nb/\/dev\/drbd/" < /etc/fstab > /etc/fstab_new
mv /etc/fstab /etc/fstab_old ; mv /etc/fstab_new /etc/fstab
for ((i=0;i<16;i++)); do mknod /dev/drbd$i b 147 $i; done

* /etc/init.d/drbd start
* migrate all services to the just upgraded node and 
  upgrade the other node.

Re: [Drbd-dev] Re: [john.cagle@hp.com: FW: device number request for drbd]

[Lars Marowsky-Bree]

On 2004-07-28T16:55:18,
   Philipp Reisner <philipp.reisner@linbit.com> said:

> Yes I want to do this. Rolling upgrades are possible. 
> I do not think that anybody actually cares about the major number 
> or the name of the device node. 

Thanks for the 0.6 -> 0.7 upgrade path.

> DRBD upgrade instructions from 0.7.0 to 0.7.1
> 
> With drbd-0.7.1 we have our own major number, and our own device
> files. (=No longer misuse /dev/nbX)
> 
> * Start on the node, on which all devices are secondary.
> * /etc/init.d/drbd stop
> * Install drbd-0.7.1
> * Run these commands as root:
> 
> sed -e "s/\/dev\/nb/\/dev\/drbd/" < /etc/drbd.conf > /etc/drbd.conf_new
> mv /etc/drbd.conf /etc/drbd.conf_old ; mv /etc/drbd.conf_new /etc/drbd.conf
> sed -e "s/\/dev\/nb/\/dev\/drbd/" < /etc/fstab > /etc/fstab_new
> mv /etc/fstab /etc/fstab_old ; mv /etc/fstab_new /etc/fstab
> for ((i=0;i<16;i++)); do mknod /dev/drbd$i b 147 $i; done
> 
> * /etc/init.d/drbd start
> * migrate all services to the just upgraded node and 
>   upgrade the other node.

You need to manually fix the application configuration files up, custom
scripts etc - for example, you forgot heartbeat's haresources, and if
someone is running raw device access to drbd w/ a database...

This is _not_ a change we can push out. The major number _might_ be
changed, but the device path absolutely has to stay stable.

You'll have to allow a transition period where we accept and work with
the old configuration and setups, allow and encourage the sane new way
for new deployments, and eventually "force" the migration in 0.8.x.

0.7.0 -> 0.7.1 must work by just dropping it in place of the old
version, or I'm going to have to patch that.


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering	    \ ever tried. ever failed. no matter.
SUSE Labs, Research and Development | try again. fail again. fail better.
SUSE LINUX AG - A Novell company    \ 	-- Samuel Beckett

Re: [Drbd-dev] Re: [john.cagle@hp.com: FW: device number request for drbd]

[Lars Ellenberg]

/ 2004-07-28 17:33:14 +0200
\ Lars Marowsky-Bree:
> On 2004-07-28T16:55:18,
>    Philipp Reisner <philipp.reisner@linbit.com> said:
> 
> > Yes I want to do this. Rolling upgrades are possible. 
> > I do not think that anybody actually cares about the major number 
> > or the name of the device node. 
> 
> Thanks for the 0.6 -> 0.7 upgrade path.

> You need to manually fix the application configuration files up, custom
> scripts etc - for example, you forgot heartbeat's haresources, and if
> someone is running raw device access to drbd w/ a database...
> 
> This is _not_ a change we can push out. The major number _might_ be
> changed, but the device path absolutely has to stay stable.

Um. now, nobody actually has drbd 0.7.0 in production yet.
Or am I wrong?

and, you always can do rm /dev/nb0 ; ln -s /dev/{drbd0,nb0}
 :-) 


> You'll have to allow a transition period where we accept and work with
> the old configuration and setups, allow and encourage the sane new way
> for new deployments, and eventually "force" the migration in 0.8.x.
> 
> 0.7.0 -> 0.7.1 must work by just dropping it in place of the old
> version, or I'm going to have to patch that.

0.7.0 had a configurable major_nr as module parameter.
I could put that back in, (I only commented it anyways),
but now default it to be LANANA_DRBD_MAJOR now, instead of NBD_MAJOR.
when it is NBD_MAJOR, devfs name will be nbd.
if someone (suse) insists,
she can put some options major_nr=43 into modules.conf ...

konsensfähig?

	Lars

Re: [Drbd-dev] Re: [john.cagle@hp.com: FW: device number request for drbd]

[Philipp Reisner]

Am Mittwoch, 28. Juli 2004 17:33 schrieb Lars Marowsky-Bree:
> On 2004-07-28T16:55:18,
>
>    Philipp Reisner <philipp.reisner@linbit.com> said:
> > Yes I want to do this. Rolling upgrades are possible.
> > I do not think that anybody actually cares about the major number
> > or the name of the device node.
>
> Thanks for the 0.6 -> 0.7 upgrade path.
>
> > DRBD upgrade instructions from 0.7.0 to 0.7.1
> >
> > With drbd-0.7.1 we have our own major number, and our own device
> > files. (=No longer misuse /dev/nbX)
> >
> > * Start on the node, on which all devices are secondary.
> > * /etc/init.d/drbd stop
> > * Install drbd-0.7.1
> > * Run these commands as root:
> >
> > sed -e "s/\/dev\/nb/\/dev\/drbd/" < /etc/drbd.conf > /etc/drbd.conf_new
> > mv /etc/drbd.conf /etc/drbd.conf_old ; mv /etc/drbd.conf_new
> > /etc/drbd.conf sed -e "s/\/dev\/nb/\/dev\/drbd/" < /etc/fstab >
> > /etc/fstab_new
> > mv /etc/fstab /etc/fstab_old ; mv /etc/fstab_new /etc/fstab
> > for ((i=0;i<16;i++)); do mknod /dev/drbd$i b 147 $i; done
> >
> > * /etc/init.d/drbd start
> > * migrate all services to the just upgraded node and
> >   upgrade the other node.
>
> You need to manually fix the application configuration files up, custom
> scripts etc - for example, you forgot heartbeat's haresources, and if
> someone is running raw device access to drbd w/ a database...
>
> This is _not_ a change we can push out. The major number _might_ be
> changed, but the device path absolutely has to stay stable.

Maybe 
for ((i=0;i<16;i++)); do mknod /dev/nb$i b 147 $i; done

Currently you can not use NBD on a system on which DRBD is active.
So creating the /dev/nbX with DRBD's major number in SuSE's upgrade
path does not make anyhing worse...

But it preserves the "application configuration files & custom scripts"
compatibility...

PS: Thx for pointing out that heartbeat's haresources file is missing
    from the upgrade 

-Philipp

Re: [Drbd-dev] Re: [john.cagle@hp.com: FW: device number request for drbd]

[Lars Ellenberg]

/ 2004-07-28 19:56:09 +0200
\ Philipp Reisner:
> > You need to manually fix the application configuration files up, custom
> > scripts etc - for example, you forgot heartbeat's haresources, and if
> > someone is running raw device access to drbd w/ a database...
> >
> > This is _not_ a change we can push out. The major number _might_ be
> > changed, but the device path absolutely has to stay stable.
> 
> Maybe 
> for ((i=0;i<16;i++)); do mknod /dev/nb$i b 147 $i; done

> Currently you can not use NBD on a system on which DRBD is active.
> So creating the /dev/nbX with DRBD's major number in SuSE's upgrade
> path does not make anyhing worse...
> 
> But it preserves the "application configuration files & custom scripts"
> compatibility...

I'd rather go for symlinks, if it really needs to be that way ...

> PS: Thx for pointing out that heartbeat's haresources file is missing
>     from the upgrade 

it is for the Filesystem resource, right?
"mount: no such device" ... outch! :-/

anyways:
do we have consense to keep the major_nr module parameter?
maybe only allow two major numbers, NBD_MAJOR and LANANA_DRBD_MAJOR.
then the parameter is not "major_nr=%d", but rather "use_nbd_major" ...
and it should clearly be marked as deprecated in the description,
and be a little bit noisy on device registration :-)

	Lars

Re: [Drbd-dev] Re: [john.cagle@hp.com: FW: device number request for drbd]

[Lars Marowsky-Bree]

On 2004-07-28T19:56:09,
   Philipp Reisner <philipp.reisner@linbit.com> said:

> > This is _not_ a change we can push out. The major number _might_ be
> > changed, but the device path absolutely has to stay stable.
> 
> Maybe 
> for ((i=0;i<16;i++)); do mknod /dev/nb$i b 147 $i; done

No. Because the user might have the RPM installed (thus the post-install
would get triggered on update), but may in fact be using nbd.

We'll have to make the drbd we ship default to the old major/minor and
also keep the examples consistent with that.

However, we can advise them use the different major in the future, but
for a GA'ed product, we cannot break what is essentially the ABI to
userspace.



Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering	    \ ever tried. ever failed. no matter.
SUSE Labs, Research and Development | try again. fail again. fail better.
SUSE LINUX AG - A Novell company    \ 	-- Samuel Beckett

Re: [Drbd-dev] Re: [john.cagle@hp.com: FW: device number request for drbd]

[Philipp Reisner]

On Friday 30 July 2004 00:32, Lars Marowsky-Bree wrote:
> On 2004-07-28T19:56:09,
>
>    Philipp Reisner <philipp.reisner@linbit.com> said:
> > > This is _not_ a change we can push out. The major number _might_ be
> > > changed, but the device path absolutely has to stay stable.
> >
> > Maybe
> > for ((i=0;i<16;i++)); do mknod /dev/nb$i b 147 $i; done
>
> No. Because the user might have the RPM installed (thus the post-install
> would get triggered on update), but may in fact be using nbd.
>
> We'll have to make the drbd we ship default to the old major/minor and
> also keep the examples consistent with that.
>
> However, we can advise them use the different major in the future, but
> for a GA'ed product, we cannot break what is essentially the ABI to
> userspace.
>
>

So then, we will reenable the major_nr module parameter. 
Then SuSE only needs to patch the init script to pass the module parameter..

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

Re: [Drbd-dev] Re: [john.cagle@hp.com: FW: device number request for drbd]

[Philipp Reisner]

On Friday 30 July 2004 11:56, Philipp Reisner wrote:
> On Friday 30 July 2004 00:32, Lars Marowsky-Bree wrote:
> > On 2004-07-28T19:56:09,
> >
> >    Philipp Reisner <philipp.reisner@linbit.com> said:
> > > > This is _not_ a change we can push out. The major number _might_ be
> > > > changed, but the device path absolutely has to stay stable.
> > >
> > > Maybe
> > > for ((i=0;i<16;i++)); do mknod /dev/nb$i b 147 $i; done
> >
> > No. Because the user might have the RPM installed (thus the post-install
> > would get triggered on update), but may in fact be using nbd.
> >
> > We'll have to make the drbd we ship default to the old major/minor and
> > also keep the examples consistent with that.
> >
> > However, we can advise them use the different major in the future, but
> > for a GA'ed product, we cannot break what is essentially the ABI to
> > userspace.
>
> So then, we will reenable the major_nr module parameter.
> Then SuSE only needs to patch the init script to pass the module
> parameter..
>

You could even use the supplied init script and put
ADD_MOD_PARAM="major_nr=43" into /etc/default/drbd

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

Re: [Drbd-dev] Re: [john.cagle@hp.com: FW: device number request for drbd]

[Lars Ellenberg]

/ 2004-07-30 13:32:20 +0200
\ Philipp Reisner:
> On Friday 30 July 2004 11:56, Philipp Reisner wrote:
> > On Friday 30 July 2004 00:32, Lars Marowsky-Bree wrote:
> > > On 2004-07-28T19:56:09,
> > >
> > >    Philipp Reisner <philipp.reisner@linbit.com> said:
> > > > > This is _not_ a change we can push out. The major number _might_ be
> > > > > changed, but the device path absolutely has to stay stable.
> > > >
> > > > Maybe
> > > > for ((i=0;i<16;i++)); do mknod /dev/nb$i b 147 $i; done
> > >
> > > No. Because the user might have the RPM installed (thus the post-install
> > > would get triggered on update), but may in fact be using nbd.
> > >
> > > We'll have to make the drbd we ship default to the old major/minor and
> > > also keep the examples consistent with that.
> > >
> > > However, we can advise them use the different major in the future, but
> > > for a GA'ed product, we cannot break what is essentially the ABI to
> > > userspace.
> >
> > So then, we will reenable the major_nr module parameter.
> > Then SuSE only needs to patch the init script to pass the module
> > parameter..
> >
> 
> You could even use the supplied init script and put
> ADD_MOD_PARAM="major_nr=43" into /etc/default/drbd

patch will follow soon which will replace that with
"use_nbd_major"

ok?

	lge

Re: [Drbd-dev] Re: [john.cagle@hp.com: FW: device number request for drbd]

[Philipp Reisner]

On Friday 30 July 2004 14:14, Lars Ellenberg wrote:
> / 2004-07-30 13:32:20 +0200
>
> \ Philipp Reisner:
> > On Friday 30 July 2004 11:56, Philipp Reisner wrote:
> > > On Friday 30 July 2004 00:32, Lars Marowsky-Bree wrote:
> > > > On 2004-07-28T19:56:09,
> > > >
> > > >    Philipp Reisner <philipp.reisner@linbit.com> said:
> > > > > > This is _not_ a change we can push out. The major number _might_
> > > > > > be changed, but the device path absolutely has to stay stable.
> > > > >
> > > > > Maybe
> > > > > for ((i=0;i<16;i++)); do mknod /dev/nb$i b 147 $i; done
> > > >
> > > > No. Because the user might have the RPM installed (thus the
> > > > post-install would get triggered on update), but may in fact be using
> > > > nbd.
> > > >
> > > > We'll have to make the drbd we ship default to the old major/minor
> > > > and also keep the examples consistent with that.
> > > >
> > > > However, we can advise them use the different major in the future,
> > > > but for a GA'ed product, we cannot break what is essentially the ABI
> > > > to userspace.
> > >
> > > So then, we will reenable the major_nr module parameter.
> > > Then SuSE only needs to patch the init script to pass the module
> > > parameter..
> >
> > You could even use the supplied init script and put
> > ADD_MOD_PARAM="major_nr=43" into /etc/default/drbd
>
> patch will follow soon which will replace that with
> "use_nbd_major"
>
> ok?
>

Ist auch ok...

... blos will ich recht bald das .tar.gz machen...

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

Re: [Drbd-dev] Re: [john.cagle@hp.com: FW: device number request for drbd]

[Lars Marowsky-Bree]

On 2004-07-30T14:14:01,
   Lars Ellenberg <Lars.Ellenberg@linbit.com> said:

> > You could even use the supplied init script and put
> > ADD_MOD_PARAM="major_nr=43" into /etc/default/drbd
> 
> patch will follow soon which will replace that with
> "use_nbd_major"

BTW, in real life our maintenance crew has rejected this. I will have to
patch the module to default to the old major by default. Upgrading the
kernel must work w/o updating the user-space at the same time, I'm
afraid.

We are in maintenance only mode already, so it's a matter of policy; we
only do bugfixes and security changes right now.

I can probably re-align with the first service-pack in March or so,
where we can "force" the customers to swallow a bigger chunk of packages
as a single bite.

Changing such fundamental behaviour in a stable series really is not
very good. You are breaking the kernel/user-space boundary. Nobody cares
what you do _in_ the kernel, or _within_ user-space, but this really
ain't good. Common policy for stable series (also adhered to by most
other projects) is _never_ to change the default.

I'll need to check whether that works, or whether the ioctls etc also
break, which would be very bad. That's just not a thing to do within a
stable series, but maybe we have different concepts of "stable" ;)


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering	    \        This space          /
SUSE Labs, Research and Development |       intentionally        |
SUSE LINUX AG - A Novell company    \        left blank          /

Re: [Drbd-dev] Re: [john.cagle@hp.com: FW: device number request for drbd]

[Philipp Reisner]

Am Mittwoch, 18. August 2004 20:42 schrieb Lars Marowsky-Bree:
> On 2004-07-30T14:14:01,
>
>    Lars Ellenberg <Lars.Ellenberg@linbit.com> said:
> > > You could even use the supplied init script and put
> > > ADD_MOD_PARAM="major_nr=43" into /etc/default/drbd
> >
> > patch will follow soon which will replace that with
> > "use_nbd_major"
>
> BTW, in real life our maintenance crew has rejected this. I will have to
> patch the module to default to the old major by default. Upgrading the
> kernel must work w/o updating the user-space at the same time, I'm
> afraid.
>
> We are in maintenance only mode already, so it's a matter of policy; we
> only do bugfixes and security changes right now.
>
> I can probably re-align with the first service-pack in March or so,
> where we can "force" the customers to swallow a bigger chunk of packages
> as a single bite.
>
> Changing such fundamental behaviour in a stable series really is not
> very good. You are breaking the kernel/user-space boundary. Nobody cares
> what you do _in_ the kernel, or _within_ user-space, but this really
> ain't good. Common policy for stable series (also adhered to by most
> other projects) is _never_ to change the default.
>
> I'll need to check whether that works, or whether the ioctls etc also
> break, which would be very bad. That's just not a thing to do within a
> stable series, but maybe we have different concepts of "stable" ;)
>

Ok, go on with whatever you think (or your policies instruct you to) is
the right way. The patch is rather trivial.

Index: drbd/drbd_main.c
===================================================================
--- drbd/drbd_main.c    (revision 1491)
+++ drbd/drbd_main.c    (working copy)
@@ -128,7 +128,7 @@
 #endif

 // module parameter, defined
-int use_nbd_major = 0;
+int use_nbd_major = 1;
 int major_nr = LANANA_DRBD_MAJOR;
 #ifdef MODULE
 int minor_count = 2;

Regarding IOCTL interface. It changed from 0.7 to 0.7.1...

-Philipp

Re: [Drbd-dev] Re: [john.cagle@hp.com: FW: device number request for drbd]

[Lars Marowsky-Bree]

On 2004-08-18T21:31:35,
   Philipp Reisner <philipp.reisner@linbit.com> said:

> Regarding IOCTL interface. It changed from 0.7 to 0.7.1...

Sigh.

Then I'll either need to do some very serious patching or delay the
whole update until the first service pack.


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering	    \        This space          /
SUSE Labs, Research and Development |       intentionally        |
SUSE LINUX AG - A Novell company    \        left blank          /

Re: [Drbd-dev] Re: [john.cagle@hp.com: FW: device number request for drbd]

[Philipp Reisner]

On Thursday 19 August 2004 00:57, Lars Marowsky-Bree wrote:
> On 2004-08-18T21:31:35,
>
>    Philipp Reisner <philipp.reisner@linbit.com> said:
> > Regarding IOCTL interface. It changed from 0.7 to 0.7.1...
>
> Sigh.
>
> Then I'll either need to do some very serious patching or delay the
> whole update until the first service pack.
>
>

I will look into it, probabely it is easy to do... [I can not remeber
what we changed there...]

BTW: I thought that RPMs have dependencies too. Why is it not possible
     to express something like

     km_drbd-0.7.1 requires  >=  drbd-0.7.1 (user-package)

     in the dependencies of the kernel module package...

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

Re: [Drbd-dev] Re: [john.cagle@hp.com: FW: device number request for drbd]

[Lars Marowsky-Bree]

On 2004-08-19T11:15:41,
   Philipp Reisner <philipp.reisner@linbit.com> said:

> I will look into it, probabely it is easy to do... [I can not remeber
> what we changed there...]

I'm also sweet-talking our maintenance crew because I really want to
avoid that ;-)

> BTW: I thought that RPMs have dependencies too. Why is it not possible
>      to express something like
> 
>      km_drbd-0.7.1 requires  >=  drbd-0.7.1 (user-package)
> 
>      in the dependencies of the kernel module package...

Because YaST2 Online Update does not evaluate these dependencies.
("Updates are not allowed to change package dependencies in a stable
product.")

So, I'm not happy with either the change in drbd nor our online update
system - either one on it's own would be fine, but the combination
thereof is somewhat annoying ;-)

But, there's hope, I think. I'll try to weasle out of that policy. I can
be really good with weasel words. ;)

(I also don't think any drbd using customer would only update the
kernel, but not drbd, or update drbd user-space but not the kernel.
I claim that's a somewhat ridiculous policy in this case...)


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering	    \        This space          /
SUSE Labs, Research and Development |       intentionally        |
SUSE LINUX AG - A Novell company    \        left blank          /