Mailing List Archive

Philipp Reisner wrote:

> Am Don, 28 Sep 2000 schrieb Thomas Mangin:
> >Philipp Reisner wrote:
> >
> >>
> >> /etc/ha.d/resource.d/datadisk [device] {start|stop|status}
> >> used by heartbeat to switch a/all drbd's devices roles (PRI/SEC).
> >> I think this one should also handle the status command.
> >> Probabely it should return "running" if the device is in primary
> >> mode and "ready" if the device is in secondary mode.
> >> If this device is seconday and still syncing it should return
> >> "not ready".
> >
> >Can you give me more infos.
> >
> >You want no ready if the master or the slave are syncing
> >or only if the slave is syncing ??
> >
>
> I am thinking:
>
> Primary, syncing ==> Running (Since the FS is mounted on top of it)

What exectly the syncing means in this context ?

> Secondary, connected ==> Stopped (Since it is possible to make this primary)
> Secondary, syncing ==> "not ready" (Since it is not possible to make this
> primary and to mount the FS on it, because
> during the resync the FS on the device
> is not in consistent state)

Can you give us/me more information on the output of the file. I will have a look
in
drbd.c but I am not sure to get all the logic behinf it ..

Thomas

Am Sam, 30 Sep 2000 schrieb root:
>Philipp Reisner wrote:
>
>> Am Don, 28 Sep 2000 schrieb Thomas Mangin:
>> >Philipp Reisner wrote:
>> >
>> >>
>> >> /etc/ha.d/resource.d/datadisk [device] {start|stop|status}
>> >> used by heartbeat to switch a/all drbd's devices roles (PRI/SEC).
>> >> I think this one should also handle the status command.
>> >> Probabely it should return "running" if the device is in primary
>> >> mode and "ready" if the device is in secondary mode.
>> >> If this device is seconday and still syncing it should return
>> >> "not ready".
>> >
>> >Can you give me more infos.
>> >
>> >You want no ready if the master or the slave are syncing
>> >or only if the slave is syncing ??
>> >
>>
>> I am thinking:
>>
>> Primary, syncing ==> Running (Since the FS is mounted on top of it)
>
>What exectly the syncing means in this context ?

With "syncing" I mean that the "cs:" field of /proc/drbd says "SyncingAll"
or "SyncingQuick"

>
>> Secondary, connected ==> Stopped (Since it is possible to make this primary)
>> Secondary, syncing ==> "not ready" (Since it is not possible to make this
>> primary and to mount the FS on it, because
>> during the resync the FS on the device
>> is not in consistent state)
>
>Can you give us/me more information on the output of the file. I will have a look
>in
>drbd.c but I am not sure to get all the logic behinf it ..
>

You can find a description of /proc/drbd at
http://www.complang.tuwien.ac.at/reisner/drbd/drbdsetup.html

to exress my last posting in other words:

"datadisk /dev/nbX status" should print
"Running" if the device's line in /proc/drbd contains "st:Primary"
"Stoppend" if the device's line in /proc/drbd contains
"st:Secondary" and "cs:connected"
"not ready" if the device's line in /proc/drbd contains
"st:Secondary" and not "cs:connected"


-Philipp

On Sat, Sep 30, 2000 at 10:12:19AM +0200, Philipp Reisner wrote:
> Am Fre, 29 Sep 2000 schrieb David Gould:
> >On Thu, Sep 28, 2000 at 09:21:44AM +0100, Thomas Mangin wrote:
> >> Dan Yocum wrote:
> >>
> >> Start -> master
> >> Stop -> slave
> >> Status -> Running if Master only
> >
> >This is very similar to what FailSafe needs. Right now we have Failsafe
> >resource scripts that call datadisk. They assume that the module is loaded
> >and devices configured at boot time and that "start" makes us the master,
> >and "stop" makes us the slave.
> >
> >I guess I should point out that heartbeat is not the only clustermanager
> >out there, so when we change the interface to drbd we risk breaking
> >something. Perhaps keeping the old version available would help.
> >
> >-dg
>
> What's about contributing the drbd-glue-to-failsave scripts to drbd.
> As I understand it FailSave is a rather stable product (or at least it's
> interfaces I think) whild DRBD is currently a moving target.

Failsafe is GPL, and I will be contributing my "resource type" (the FS
term for the glue) to Failsafe. You are welcome to it too.

But, not just yet...

Josh and I are reworking the scripting interfaces to Failsafe to make
it much easier to create the resource type bindings. The original scheme
was somewhat confusing. Our plan is to provide for creating resource
bindings in bash, perl, and python. bash and perl are mostly done
but need some testing and polishing.

I will try to finish up the perl bindings (the DRBD resource type uses them)
and send it off to sgi to add to Failsafe. If you like, I can send you a
copy then.

Actually, if you want, I can send you one now, but I am not quite done
with pushing the interfaces around, so let me know...


On another subject, I still think of making the drbd config files into
one file. At linuxworld suse showed a four node Failsafe cluster and each
node had five drbd partitions. While we were setting it up, the
ip addresses had to be changed a couple times, and the partition names
and mount points changed a couple times, and each time we had to hand
edit 20 drbdx files. And screw up a couple times and do it over... Yecch.

Basically, I want one file that I can put all the nodes and all the
partitions in and change once in one place and rdist it to the rest
of the cluster.

-dg

--
David Gould dg@example.com
SuSE, Inc., 580 2cd St. #210, Oakland, CA 94607 510.628.3380
"So many ways to skin a cat, and still everyone uses a great big knife."

Hello phillip,

Once again this week I worked on the script. The code is now much cleaner and
must be understandable.
I intruduce the different "mode" . The configuration file had other changes
needed to be able to handle more than 2 nodes. The code is still under heavy
change but I be happy to get feedback ..

As a bug report Redhat 7.0, it compile and the module can be inserted but
drdbsetup report :
can not open device: No such device
strace report the problem to be a impossibility to "open" /dev/nb0 (the module
nbd.o is NOT loaded)

I am hunting the lat bug, but a feedback on the struture of the script would be
welcome as well as a explaination of the possible /proc/drbd output

Have a good WE.

Thomas

On Sat, 30 Sep 2000, David Gould wrote:

> On Sat, Sep 30, 2000 at 10:12:19AM +0200, Philipp Reisner wrote:
> > Am Fre, 29 Sep 2000 schrieb David Gould:
> > >On Thu, Sep 28, 2000 at 09:21:44AM +0100, Thomas Mangin wrote:
> > >> Dan Yocum wrote:
> > >>
> > >> Start -> master
> > >> Stop -> slave
> > >> Status -> Running if Master only
> > >
> > >This is very similar to what FailSafe needs. Right now we have Failsafe
> > >resource scripts that call datadisk. They assume that the module is loaded
> > >and devices configured at boot time and that "start" makes us the master,
> > >and "stop" makes us the slave.
> > >
> > >I guess I should point out that heartbeat is not the only clustermanager
> > >out there, so when we change the interface to drbd we risk breaking
> > >something. Perhaps keeping the old version available would help.
> > >
> > >-dg
> >
> > What's about contributing the drbd-glue-to-failsave scripts to drbd.
> > As I understand it FailSave is a rather stable product (or at least it's
> > interfaces I think) whild DRBD is currently a moving target.
>
> Failsafe is GPL, and I will be contributing my "resource type" (the FS
> term for the glue) to Failsafe. You are welcome to it too.
>
> But, not just yet...
>
> Josh and I are reworking the scripting interfaces to Failsafe to make
> it much easier to create the resource type bindings. The original scheme
> was somewhat confusing. Our plan is to provide for creating resource
> bindings in bash, perl, and python. bash and perl are mostly done
> but need some testing and polishing.
>
> I will try to finish up the perl bindings (the DRBD resource type uses them)
> and send it off to sgi to add to Failsafe. If you like, I can send you a
> copy then.
>
> Actually, if you want, I can send you one now, but I am not quite done
> with pushing the interfaces around, so let me know...
>
>
> On another subject, I still think of making the drbd config files into
> one file. At linuxworld suse showed a four node Failsafe cluster and each
> node had five drbd partitions. While we were setting it up, the
> ip addresses had to be changed a couple times, and the partition names
> and mount points changed a couple times, and each time we had to hand
> edit 20 drbdx files. And screw up a couple times and do it over... Yecch.
>
> Basically, I want one file that I can put all the nodes and all the
> partitions in and change once in one place and rdist it to the rest
> of the cluster.
>

Ok, now we have one file for each drbd device. But this file is
"node independend" -- you can edit it on one node and rdist it
to the other node.

If your single config file is "node independend" too, write a
parser to read it, and send the patches to me and/or Thomas.

PS: I have not mentioned before on the list, if someone wants
access to CVS, send me a mail, and include a little note
about what you want to do.

-Philipp

On Tue, Oct 03, 2000 at 09:48:07AM +0200, Philipp Reisner wrote:
> On Sat, 30 Sep 2000, David Gould wrote:
>
> > On another subject, I still think of making the drbd config files into
> > one file. At linuxworld suse showed a four node Failsafe cluster and each
> > node had five drbd partitions. While we were setting it up, the
> > ip addresses had to be changed a couple times, and the partition names
> > and mount points changed a couple times, and each time we had to hand
> > edit 20 drbdx files. And screw up a couple times and do it over... Yecch.
> >
> > Basically, I want one file that I can put all the nodes and all the
> > partitions in and change once in one place and rdist it to the rest
> > of the cluster.
> >
>
> Ok, now we have one file for each drbd device. But this file is
> "node independend" -- you can edit it on one node and rdist it
> to the other node.

Except that it is only node independant for the two node case. I am trying
to work with larger clusters eg: four machines with two drbd pairs ...

fe A -> drbd ->B
be C -> drbd ->D

> If your single config file is "node independend" too, write a
> parser to read it, and send the patches to me and/or Thomas.

My idea is that in a single cluster there is exactly on drbd config
file and each node knows by it's own ip what units/lines in it apply.

> PS: I have not mentioned before on the list, if someone wants
> access to CVS, send me a mail, and include a little note
> about what you want to do.

Thanks. When I understand a bit more about the module, and have something
tasty to contribute I may ask about this...

-dg

--
David Gould dg@example.com
SuSE, Inc., 580 2cd St. #210, Oakland, CA 94607 510.628.3380
"So many ways to skin a cat, and still everyone uses a great big knife."

> > Ok, now we have one file for each drbd device. But this file is
> > "node independend" -- you can edit it on one node and rdist it
> > to the other node.
>
> Except that it is only node independant for the two node case. I am trying
> to work with larger clusters eg: four machines with two drbd pairs ...
>
> fe A -> drbd ->B
> be C -> drbd ->D
>
> > If your single config file is "node independend" too, write a
> > parser to read it, and send the patches to me and/or Thomas.
>
> My idea is that in a single cluster there is exactly on drbd config
> file and each node knows by it's own ip what units/lines in it apply.

As a side effect of removing master_slave, I think that the new
configuration
file can handle this kind of configuration. ;*)

Did I code something usefull, no it can not be ;*)
Have a look into CVS before coding anything ...

Thomas

On 2000-10-03T03:20:21,
David Gould <dg@example.com> said:

> > If your single config file is "node independend" too, write a
> > parser to read it, and send the patches to me and/or Thomas.
> My idea is that in a single cluster there is exactly on drbd config
> file and each node knows by it's own ip what units/lines in it apply.

Sounds good.

Please provide provision (if possible) for generating that file on the fly
from lets say a Cluster Database in the background, leaving configuration
management to the cluster manager.

Sincerely,
Lars Marowsky-Brée <lmb@example.com>
Development HA

--
Perfection is our goal, excellence will be tolerated. -- J. Yahl

David Gould wrote:
>
> On Thu, Sep 28, 2000 at 09:21:44AM +0100, Thomas Mangin wrote:
> > Dan Yocum wrote:
> >
> > > OK guys, heartbeat (actually ResourceManager in heartbeat) *needs* to
> > > be able to issue these three commands to drbdc:
> > >
> > > start
> > > stop
> > > status
> > >
> > > And when it does a 'status' it *needs* to see either 'running' or
> > > 'Running' in the output if the service is available (i.e., if the volume
> > > is mounted and Primary) not the contents of /proc/drbd.
> > >
> > > Don't kill the messenger. ;)
> > >
> > > Cheers,
> > > Dan
> >
> > Start -> master
> > Stop -> slave
> > Status -> Running if Master only
>
> This is very similar to what FailSafe needs. Right now we have Failsafe
> resource scripts that call datadisk. They assume that the module is loaded
> and devices configured at boot time and that "start" makes us the master,
> and "stop" makes us the slave.

Yes. Thomas didn't change this portion (did you?) so it will act the
same as before... heartbeat specifically wants to see the word 'running'
when a 'datadisk status' is issued. This keeps with the norm of other
SysV rc 'status' reports and should not be anything new. This ain't a
curve ball...

Dan


--
Dan Yocum, Sr. Linux Consultant
Linuxcare, Inc.
630.697.8066 tel
yocum@example.com, http://www.linuxcare.com

Linuxcare. Support for the revolution.

On 2000-10-03T11:30:05,
Dan Yocum <yocum@example.com> said:

> Yes. Thomas didn't change this portion (did you?) so it will act the
> same as before... heartbeat specifically wants to see the word 'running'
> when a 'datadisk status' is issued. This keeps with the norm of other
> SysV rc 'status' reports and should not be anything new. This ain't a
> curve ball...

heartbeak will also accept "ok", and of course, this can be changed in the
heartbeat resource scripts...

Sincerely,
Lars Marowsky-Brée <lmb@example.com>
Development HA

--
Perfection is our goal, excellence will be tolerated. -- J. Yahl

Dan Yocum wrote:
>
> David Gould wrote:
> >
> > On Thu, Sep 28, 2000 at 09:21:44AM +0100, Thomas Mangin wrote:
> > > Dan Yocum wrote:
> > >
> > > > OK guys, heartbeat (actually ResourceManager in heartbeat) *needs* to
> > > > be able to issue these three commands to drbdc:
> > > >
> > > > start
> > > > stop
> > > > status
> > > >
> > > > And when it does a 'status' it *needs* to see either 'running' or
> > > > 'Running' in the output if the service is available (i.e., if the volume
> > > > is mounted and Primary) not the contents of /proc/drbd.
> > > >
> > > > Don't kill the messenger. ;)
> > > >
> > > > Cheers,
> > > > Dan
> > >
> > > Start -> master
> > > Stop -> slave
> > > Status -> Running if Master only
> >
> > This is very similar to what FailSafe needs. Right now we have Failsafe
> > resource scripts that call datadisk. They assume that the module is loaded
> > and devices configured at boot time and that "start" makes us the master,
> > and "stop" makes us the slave.
>
> Yes. Thomas didn't change this portion (did you?) so it will act the
> same as before... heartbeat specifically wants to see the word 'running'
> when a 'datadisk status' is issued. This keeps with the norm of other
> SysV rc 'status' reports and should not be anything new. This ain't a
> curve ball...

YES I DID, it took me long enough. ;*)
I rewrote half of the code this WE.
Can you now check it is retirning what Heartbeat is expecting !!

Thomas

> > > Yes. Thomas didn't change this portion (did you?) so it will act the
> > > same as before... heartbeat specifically wants to see the word 'running'
> > > when a 'datadisk status' is issued. This keeps with the norm of other
> > > SysV rc 'status' reports and should not be anything new. This ain't a
> > > curve ball...
> >
> > YES I DID, it took me long enough. ;*)
> > I rewrote half of the code this WE.
> > Can you now check it is retirning what Heartbeat is expecting !!
>
> OK, ok, ok... what I meant was, that the functionality hasn't changed...
> 'start' still starts it (makes it primary, mounts it, etc.); 'stop'
> still stops it (makes it secondary, unmounts, etc.); and 'status' does
> what heartbeat expects - issue a 'running' message when it is, and
> something else when it isn't.
>
> Yes, you rewrote it a lot and changed the internals, generalized things,
> etc. for which *I* am grateful, as I'm sure others are as well.
>
> I will update my version of CVS *right now* and let you know how it
> goes. There are no typo's right? ;)

Sorry if my tone sounded rush, I didn't wanted to look bad ..
I am a nice person, at least my mother says it ;*)

I am pleased to see you are "grateful" for those few hours I spent with
datadisk but it was not necessary, just reporting me bug and telling me
where my code is crap will do ;*)

Thomas

Thomas Mangin wrote:
>
> Dan Yocum wrote:
> >
> > David Gould wrote:
> > >
> > > On Thu, Sep 28, 2000 at 09:21:44AM +0100, Thomas Mangin wrote:
> > > > Dan Yocum wrote:
> > > >
> > > > > OK guys, heartbeat (actually ResourceManager in heartbeat) *needs* to
> > > > > be able to issue these three commands to drbdc:
> > > > >
> > > > > start
> > > > > stop
> > > > > status
> > > > >
> > > > > And when it does a 'status' it *needs* to see either 'running' or
> > > > > 'Running' in the output if the service is available (i.e., if the volume
> > > > > is mounted and Primary) not the contents of /proc/drbd.
> > > > >
> > > > > Don't kill the messenger. ;)
> > > > >
> > > > > Cheers,
> > > > > Dan
> > > >
> > > > Start -> master
> > > > Stop -> slave
> > > > Status -> Running if Master only
> > >
> > > This is very similar to what FailSafe needs. Right now we have Failsafe
> > > resource scripts that call datadisk. They assume that the module is loaded
> > > and devices configured at boot time and that "start" makes us the master,
> > > and "stop" makes us the slave.
> >
> > Yes. Thomas didn't change this portion (did you?) so it will act the
> > same as before... heartbeat specifically wants to see the word 'running'
> > when a 'datadisk status' is issued. This keeps with the norm of other
> > SysV rc 'status' reports and should not be anything new. This ain't a
> > curve ball...
>
> YES I DID, it took me long enough. ;*)
> I rewrote half of the code this WE.
> Can you now check it is retirning what Heartbeat is expecting !!

OK, ok, ok... what I meant was, that the functionality hasn't changed...
'start' still starts it (makes it primary, mounts it, etc.); 'stop'
still stops it (makes it secondary, unmounts, etc.); and 'status' does
what heartbeat expects - issue a 'running' message when it is, and
something else when it isn't.

Yes, you rewrote it a lot and changed the internals, generalized things,
etc. for which *I* am grateful, as I'm sure others are as well.

I will update my version of CVS *right now* and let you know how it
goes. There are no typo's right? ;)

Cheers,
Dan

--
Dan Yocum, Sr. Linux Consultant
Linuxcare, Inc.
630.697.8066 tel
yocum@example.com, http://www.linuxcare.com

Linuxcare. Support for the revolution.

Compilation on REDHAT 7.0 :

gcc -c -D__KERNEL__ -DMODULE -O2 -Wall -m486 -DCPU=586 -malign-loops=2
-malign-jumps=2 -malign-functions=2 -fomit-frame-pointer
-I/usr/src/linux/include -DMOD_VERSION=58 -DEXPORT_SYMTAB drbd.c
In file included from /usr/src/linux/include/linux/modversions.h:50,
from /usr/src/linux/include/linux/module.h:19,
from drbd.c:57:
/usr/src/linux/include/linux/modules/i386_ksyms.ver:6:18: warning:
"cpu_data" redefined
/usr/src/linux/include/asm/processor.h:96:1: warning: this is the
location of the previous definition
/usr/src/linux/include/linux/modules/i386_ksyms.ver:28:22: warning:
"smp_num_cpus" redefined
/usr/src/linux/include/linux/smp.h:77:1: warning: this is the location
of the previous definition
/usr/src/linux/include/linux/modules/i386_ksyms.ver:118:27: warning:
"smp_call_function" redefined
/usr/src/linux/include/linux/smp.h:83:1: warning: this is the location
of the previous definition
/usr/src/linux/include/linux/modules/i386_ksyms.ver:138:25: warning:
"synchronize_irq" redefined
/usr/src/linux/include/asm/hardirq.h:23:1: warning: this is the location
of the previous definition
/usr/src/linux/include/linux/modules/i386_ksyms.ver:142:24: warning:
"synchronize_bh" redefined
/usr/src/linux/include/asm/softirq.h:75:1: warning: this is the location
of the previous definition
drbd.c:1470:44: warning: pasting would not give a valid preprocessing
token
drbd.c:1470:73: warning: pasting would not give a valid preprocessing
token
drbd.c:1471:44: warning: pasting would not give a valid preprocessing
token
drbd.c:1471:73: warning: pasting would not give a valid preprocessing
token
drbd.c:1476:44: warning: pasting would not give a valid preprocessing
token
drbd.c:1476:73: warning: pasting would not give a valid preprocessing
token
drbd.c:1477:44: warning: pasting would not give a valid preprocessing
token
drbd.c:1477:73: warning: pasting would not give a valid preprocessing
token
/usr/src/linux/include/linux/blk.h:453: warning: `do_nbd_request'
declared `static' but never defined
/tmp/ccBizVIy.s: Assembler messages:
/tmp/ccBizVIy.s:9: Warning: Ignoring changed section attributes for
.modinfo

Dan Yocum wrote:
>
> Are you compiling on an SMP machine? Red Hat has been known to ship
> SMP-capable kernels for UP machines. I think this was the default in
> 6.0/1/2. You may have to recompile your kernel without the SMP support
> enabled, then recompile drbd.
>
> Dan

No as far as I can see with lilo I am booting a the
vmlinuz-2.2.16-22enterprise.
looking at dmesg I can see any smp reference..

Thomas
>
> Thomas Mangin wrote:
> >
> > Compilation on REDHAT 7.0 :
> >
> > gcc -c -D__KERNEL__ -DMODULE -O2 -Wall -m486 -DCPU=586 -malign-loops=2
> > -malign-jumps=2 -malign-functions=2 -fomit-frame-pointer
> > -I/usr/src/linux/include -DMOD_VERSION=58 -DEXPORT_SYMTAB drbd.c
> > In file included from /usr/src/linux/include/linux/modversions.h:50,
> > from /usr/src/linux/include/linux/module.h:19,
> > from drbd.c:57:
> > /usr/src/linux/include/linux/modules/i386_ksyms.ver:6:18: warning:
> > "cpu_data" redefined
> > /usr/src/linux/include/asm/processor.h:96:1: warning: this is the
> > location of the previous definition
> > /usr/src/linux/include/linux/modules/i386_ksyms.ver:28:22: warning:
> > "smp_num_cpus" redefined
> > /usr/src/linux/include/linux/smp.h:77:1: warning: this is the location
> > of the previous definition
> > /usr/src/linux/include/linux/modules/i386_ksyms.ver:118:27: warning:
> > "smp_call_function" redefined
> > /usr/src/linux/include/linux/smp.h:83:1: warning: this is the location
> > of the previous definition
> > /usr/src/linux/include/linux/modules/i386_ksyms.ver:138:25: warning:
> > "synchronize_irq" redefined
> > /usr/src/linux/include/asm/hardirq.h:23:1: warning: this is the location
> > of the previous definition
> > /usr/src/linux/include/linux/modules/i386_ksyms.ver:142:24: warning:
> > "synchronize_bh" redefined
> > /usr/src/linux/include/asm/softirq.h:75:1: warning: this is the location
> > of the previous definition
> > drbd.c:1470:44: warning: pasting would not give a valid preprocessing
> > token
> > drbd.c:1470:73: warning: pasting would not give a valid preprocessing
> > token
> > drbd.c:1471:44: warning: pasting would not give a valid preprocessing
> > token
> > drbd.c:1471:73: warning: pasting would not give a valid preprocessing
> > token
> > drbd.c:1476:44: warning: pasting would not give a valid preprocessing
> > token
> > drbd.c:1476:73: warning: pasting would not give a valid preprocessing
> > token
> > drbd.c:1477:44: warning: pasting would not give a valid preprocessing
> > token
> > drbd.c:1477:73: warning: pasting would not give a valid preprocessing
> > token
> > /usr/src/linux/include/linux/blk.h:453: warning: `do_nbd_request'
> > declared `static' but never defined
> > /tmp/ccBizVIy.s: Assembler messages:
> > /tmp/ccBizVIy.s:9: Warning: Ignoring changed section attributes for
> > .modinfo

Are you compiling on an SMP machine? Red Hat has been known to ship
SMP-capable kernels for UP machines. I think this was the default in
6.0/1/2. You may have to recompile your kernel without the SMP support
enabled, then recompile drbd.

Dan

Thomas Mangin wrote:
>
> Compilation on REDHAT 7.0 :
>
> gcc -c -D__KERNEL__ -DMODULE -O2 -Wall -m486 -DCPU=586 -malign-loops=2
> -malign-jumps=2 -malign-functions=2 -fomit-frame-pointer
> -I/usr/src/linux/include -DMOD_VERSION=58 -DEXPORT_SYMTAB drbd.c
> In file included from /usr/src/linux/include/linux/modversions.h:50,
> from /usr/src/linux/include/linux/module.h:19,
> from drbd.c:57:
> /usr/src/linux/include/linux/modules/i386_ksyms.ver:6:18: warning:
> "cpu_data" redefined
> /usr/src/linux/include/asm/processor.h:96:1: warning: this is the
> location of the previous definition
> /usr/src/linux/include/linux/modules/i386_ksyms.ver:28:22: warning:
> "smp_num_cpus" redefined
> /usr/src/linux/include/linux/smp.h:77:1: warning: this is the location
> of the previous definition
> /usr/src/linux/include/linux/modules/i386_ksyms.ver:118:27: warning:
> "smp_call_function" redefined
> /usr/src/linux/include/linux/smp.h:83:1: warning: this is the location
> of the previous definition
> /usr/src/linux/include/linux/modules/i386_ksyms.ver:138:25: warning:
> "synchronize_irq" redefined
> /usr/src/linux/include/asm/hardirq.h:23:1: warning: this is the location
> of the previous definition
> /usr/src/linux/include/linux/modules/i386_ksyms.ver:142:24: warning:
> "synchronize_bh" redefined
> /usr/src/linux/include/asm/softirq.h:75:1: warning: this is the location
> of the previous definition
> drbd.c:1470:44: warning: pasting would not give a valid preprocessing
> token
> drbd.c:1470:73: warning: pasting would not give a valid preprocessing
> token
> drbd.c:1471:44: warning: pasting would not give a valid preprocessing
> token
> drbd.c:1471:73: warning: pasting would not give a valid preprocessing
> token
> drbd.c:1476:44: warning: pasting would not give a valid preprocessing
> token
> drbd.c:1476:73: warning: pasting would not give a valid preprocessing
> token
> drbd.c:1477:44: warning: pasting would not give a valid preprocessing
> token
> drbd.c:1477:73: warning: pasting would not give a valid preprocessing
> token
> /usr/src/linux/include/linux/blk.h:453: warning: `do_nbd_request'
> declared `static' but never defined
> /tmp/ccBizVIy.s: Assembler messages:
> /tmp/ccBizVIy.s:9: Warning: Ignoring changed section attributes for
> .modinfo
> _______________________________________________
> DRBD-devel mailing list
> DRBD-devel@example.com
> http://lists.sourceforge.net/mailman/listinfo/drbd-devel

--
Dan Yocum, Sr. Linux Consultant
Linuxcare, Inc.
630.697.8066 tel
yocum@example.com, http://www.linuxcare.com

Linuxcare. Support for the revolution.

Il Wed, 04 Oct 2000, hai scritto:
> Compilation on REDHAT 7.0 :

I don't have a RH 7, but I've heard that there are some trouble with the version
of the gcc and the glibc on RH 7... On www.lwn.net you can find more datails!!!

I compile drbd on redhat 7.0. It worked for me.

Thomas
--
Thomas Mangin (mailto:thomas.mangin@example.com)
System Administrator (mailto:systems@example.com)
Legend Internet Ltd. (http://www.legend.co.uk:/)
--
The urgent is done, the impossible is on the way, for miracles expect a
small delay


----- Original Message -----
From: Gabriele Paciucci <paciucci@example.com>
To: <drbd-devel@example.com>
Sent: Sunday, October 08, 2000 9:18 AM
Subject: Re: [DRBD-dev] Configuration issue with DRBD + datadisk


> Il Wed, 04 Oct 2000, hai scritto:
> > Compilation on REDHAT 7.0 :
>
> I don't have a RH 7, but I've heard that there are some trouble with the
version
> of the gcc and the glibc on RH 7... On www.lwn.net you can find more
datails!!!
>
> _______________________________________________
> DRBD-devel mailing list
> DRBD-devel@example.com
> http://lists.sourceforge.net/mailman/listinfo/drbd-devel
>