Mailing List Archive

Hi Thomas,

> Journaling filesystems was not widely tested with drbd. As far I know you
> are the first to report a try with ext3.

Strange I'd have imagined journaling to be pretty much a prerequisite of
successfull use of drbd.

> If you look at the archive you will find that last week ??
> Marcelo said what was the best kernel for drbd.
> There is a bug in the TCP stack of 17 which is fixed in 18 ..
> My personal choice was ext2 + sync option + protocol B

So you need to run fsck on the replicated partition(s) on failover. In case
of, say, a 30GB webserver being mirrored I'd imagine failover to take a
rather long time. Am I missing something here?

> You can have a look to the script in CVS now .. They are working
> with the last heartbeat with the nice_failback option. The script code
> is going to go through a change soon.
> Don't try the script of 57 with heartbeat, It CANT work

Currently I'm running a somewhat modified version of the .57 script +
heartbeat with nice_failback; works reasonably well as long as one node
stays up all the time; if both are down the admin needs to know what he's
doing to get the cluster back up without problems.

I've tried the CVS code a bit more than a week ago; gave up in frustration
since I couldn't even get the drbd devices configured and went back to the
old scripts.

Bye, Martin

"you have moved your mouse, please reboot to make this change take effect"
--------------------------------------------------
Martin Bene vox: +43-316-813824
simon media fax: +43-316-813824-6
Nikolaiplatz 4 e-mail: mb@example.com
8020 Graz, Austria
--------------------------------------------------
finger mb@example.com for PGP public key

> So you need to run fsck on the replicated partition(s) on failover. In
case
> of, say, a 30GB webserver being mirrored I'd imagine failover to take a
> rather long time. Am I missing something here?

No, but the datadisk it will do it ;*(

> Currently I'm running a somewhat modified version of the .57 script +
> heartbeat with nice_failback; works reasonably well as long as one node
> stays up all the time; if both are down the admin needs to know what he's
> doing to get the cluster back up without problems.
>
> I've tried the CVS code a bit more than a week ago; gave up in frustration
> since I couldn't even get the drbd devices configured and went back to the
> old scripts.

No bug report !!
Bad, bad !! ;*)

Thomas

On Wed, 29 Nov 2000, Martin Bene wrote:

> Hi,
>
> I'm trying to run a couple of ha-clusters using drbd to keep disk content
> synchonized; requirements sould be fairly common:
>
> - 2.2.x kernel
> - most stable drbd version
> - a journaling filesystem to use on top of drbd
>
> Is there a general consensus on what kernel version, patches (Andreas VM
> patches?), drbd version and journaling filesystem should be least likely to
> curl up and die?

Always use protocol C with journalled filesystems.

>
> So far, I've seen a nice collection of
> * drbd loosing the connection in case of higher system/disk activity
> * heartbeat thinking the other side was down and triggering an erroneous
> takeover
> * kernel crashes with infamous "try to free pages" messages

Apply Andreas patches.

> * ext3 exceptions (ext3 thinks write ordering wasn't observed). this mostly
> happened near the moment drbd lost its connection
> * system lockups when running large data copies onto ext3 on drbd (system
> CPU goes to 100%, cp in "D" state can no longer be killed. reset button
> time.)

Have you applied my deadlock patches in drbd?

>
> Currently I'd expect drbd 5.7 + late 2.218pre kernel + Andreas VM_global_7
> patches + reiserfs to be as near to a stable system as I can get. I'm still
> seeing drbd disconnects/hangs however; especialy on systems with fast
> harddisks and slow (10Mbit) network interconnect.

Have you tried to increase timeout value?

Hi Marcelo,

> > Is there a general consensus on what kernel version, patches (Andreas VM
> > patches?), drbd version and journaling filesystem should be
> > least likely to
> > curl up and die?
>
> Always use protocol C with journalled filesystems.

OK, I can change this. I was using protocol B previously.

Could you explain why it's needed though? I'd have expected protocol B to be
sufficient: I want to ensure correct operation in case the primary node
fails and the secondary has to take over. Do I really care when the
secondary node completes its physical writes? If the secondary runs into
problems and can't complete a write request, I expect loose
synchronisattion; I also expect the primary node to go on working without
delays.

If the primary goes down, it sould be sufficient for the secondary to have
acked the data on network receipt and write the requests to disk at its
leisure; there's no unmount/reboot activity going on on the sec. node.

> Apply Andreas patches.

Yes these are always in use for my later setups / tests.

> > * ext3 exceptions (ext3 thinks write ordering wasn't
> > observed). this mostly
> > happened near the moment drbd lost its connection
> > * system lockups when running large data copies onto ext3 on
> > drbd (system
> > CPU goes to 100%, cp in "D" state can no longer be killed. reset button
> > time.)
>
> Have you applied my deadlock patches in drbd?

These occured using a CVS version of drbd - I believe your patches are
already included in current CVS code; the tests were run aroun Nov 15 I
don't recall if your patch was in the snapshout I used for the test. I'll
retest with current snapshot to make sure your patches are in use.

> > Currently I'd expect drbd 5.7 + late 2.218pre kernel + Andreas
> > VM_global_7
> > patches + reiserfs to be as near to a stable system as I can
> > get. I'm still
> > seeing drbd disconnects/hangs however; especialy on systems with fast
> > harddisks and slow (10Mbit) network interconnect.
>
> Have you tried to increase timeout value?

Not yet, I'll give this a try as well.

Bye, Martin

"you have moved your mouse, please reboot to make this change take effect"
--------------------------------------------------
Martin Bene vox: +43-316-813824
simon media fax: +43-316-813824-6
Nikolaiplatz 4 e-mail: mb@example.com
8020 Graz, Austria
--------------------------------------------------
finger mb@example.com for PGP public key

On Sat, 2 Dec 2000, Martin Bene wrote:

> Hi Marcelo,
>
> > > Is there a general consensus on what kernel version, patches (Andreas VM
> > > patches?), drbd version and journaling filesystem should be
> > > least likely to
> > > curl up and die?
> >
> > Always use protocol C with journalled filesystems.
>
> OK, I can change this. I was using protocol B previously.
>
> Could you explain why it's needed though? I'd have expected protocol B to be
> sufficient: I want to ensure correct operation in case the primary node
> fails and the secondary has to take over. Do I really care when the
> secondary node completes its physical writes?

Journalling cares :)

> If the secondary runs into
> problems and can't complete a write request, I expect loose
> synchronisattion; I also expect the primary node to go on working without
> delays.
>
> If the primary goes down, it sould be sufficient for the secondary to have
> acked the data on network receipt and write the requests to disk at its
> leisure; there's no unmount/reboot activity going on on the sec. node.

A journal transaction commit operation happens when all the data of this
transaction is guaranteed to be on disk.

If a commit operation happens before all data has hitted the disk, and a
crash happens, the recovery mechanism will assume this data is consistent
while it may not be.

With protocol B, the ack from the secondary node is sent when the write
request is received, but there is no guarantee that this write requests
has hitted the backing storage (the hard disk, in your case).

If we ack a write request to the journalling filesystem without being sure
that the data is on physical media, the situation which I explained above
can happen.

With protocol C, the ack from the secondary node is sent when the write
request has actually hitted the disk.

>
> > Apply Andreas patches.
>
> Yes these are always in use for my later setups / tests.
>
> > > * ext3 exceptions (ext3 thinks write ordering wasn't
> > > observed). this mostly
> > > happened near the moment drbd lost its connection
> > > * system lockups when running large data copies onto ext3 on
> > > drbd (system
> > > CPU goes to 100%, cp in "D" state can no longer be killed. reset button
> > > time.)
> >
> > Have you applied my deadlock patches in drbd?
>
> These occured using a CVS version of drbd - I believe your patches are
> already included in current CVS code; the tests were run aroun Nov 15 I
> don't recall if your patch was in the snapshout I used for the test. I'll
> retest with current snapshot to make sure your patches are in use.

My patch is not applied on drbd CVS yet.

> > > Currently I'd expect drbd 5.7 + late 2.218pre kernel + Andreas
> > > VM_global_7
> > > patches + reiserfs to be as near to a stable system as I can
> > > get. I'm still
> > > seeing drbd disconnects/hangs however; especialy on systems with fast
> > > harddisks and slow (10Mbit) network interconnect.
> >
> > Have you tried to increase timeout value?
>
> Not yet, I'll give this a try as well.

Ok.

Report your results :)

Hi Marcelo,

> With protocol B, the ack from the secondary node is sent when the write
> request is received, but there is no guarantee that this write requests
> has hitted the backing storage (the hard disk, in your case).
>
> If we ack a write request to the journalling filesystem without being sure
> that the data is on physical media, the situation which I explained above
> can happen.

Hmm, I still don't get why a journaling fs has different requirements wrt to
protocol compared to non-journaling fs. let me sketch my understanding of a
scenario.
Starting point: drbd device is in sync node 1 primary node 2 secondary;

Now, let's assume some write access on the primary and protocol B. This
gives us a possible time window where 1 has commited the data to disk and 2
hasn't. The data HAS however been received by drbd on node 2. Now, assume a
failure.

a) node 1 goes down.
Node 2 doesn't go down, it becomes primary. any data received and acked by
drbd should be correctly returned by a read request when going primary on
node 2. So, I'd expect failover to work without risk of corruption in this
case.

b) node 2 goes down.
Now we've definitely lost data, node 2 is no longer in sync with node 1
and node 1 doesn't know about it; the missing data will not be repaired by
quicksync when node2 comes back up again. This is the risk I take with
protocol B and sould be the same regardless wether I use a journaling or
"normal" filesystem.

So in my understanding it boils down to the choice between either using
protocol C + quicksync or protocol B + full rebuild to actually guarantee
the mirrors stay in sync if one node goes down temporarily.

> > These occured using a CVS version of drbd - I believe your patches are
> > already included in current CVS code; the tests were run aroun Nov 15 I
> > don't recall if your patch was in the snapshout I used for the
> > test. I'll retest with current snapshot to make sure your patches are in
use.
>
> My patch is not applied on drbd CVS yet.

Just to make sure: the correct patch is the one you posted on 10.16.2000
with a subject "2.2.17 drbd/nbd deadlock problem found", right?

> Report your results :)

Testing in progress now... just have to get the messed up scripts from CVS
into a state where it's actually possible to do actually USE them.

Bye, Martin

"you have moved your mouse, please reboot to make this change take effect"
--------------------------------------------------
Martin Bene vox: +43-316-813824
simon media fax: +43-316-813824-6
Nikolaiplatz 4 e-mail: mb@example.com
8020 Graz, Austria
--------------------------------------------------
finger mb@example.com for PGP public key

Hi Marcelo,

> > > > Currently I'd expect drbd 5.7 + late 2.218pre kernel + Andreas
> > > > VM_global_7
> > > > patches + reiserfs to be as near to a stable system as I can
> > > > get. I'm still
> > > > seeing drbd disconnects/hangs however; especialy on systems
> > > > with fast
> > > > harddisks and slow (10Mbit) network interconnect.

> Report your results :)

Ok, back with first results - all good so far. I'm now running:

Linux 2.2.17
Alans Pre 2.2.18pre18 patch
(ftp://ftp.at.kernel.org/pub/linux/kernel/people/alan/2.2.18pre/pre-patch-2.
2.18-18.bz2)
Andreas VM Patch
(ftp://ftp.at.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18p
re18/VM-global-2.2.18pre18-7.bz2)
Reiserfs 3.5.27
(http://www.getrewted.net/ftp.tux.org/linux-2.2.17-reiserfs-3.5.27-patch.gz)
Drbd Snapshot 0.58 from CVS
your deadlock patches
(http://www.geocrawler.com/archives/3/3756/2000/10/0/4457485/)

I haven't been able to kill the system (yet :-). If I do manage to break
things again, I'll let you know.

Bye, Martin

"you have moved your mouse, please reboot to make this change take effect"
--------------------------------------------------
Martin Bene vox: +43-316-813824
simon media fax: +43-316-813824-6
Nikolaiplatz 4 e-mail: mb@example.com
8020 Graz, Austria
--------------------------------------------------
finger mb@example.com for PGP public key

On Sun, 3 Dec 2000, Martin Bene wrote:

> Hi Marcelo,

Hi

> > With protocol B, the ack from the secondary node is sent when the write
> > request is received, but there is no guarantee that this write requests
> > has hitted the backing storage (the hard disk, in your case).
> >
> > If we ack a write request to the journalling filesystem without being sure
> > that the data is on physical media, the situation which I explained above
> > can happen.
>
> Hmm, I still don't get why a journaling fs has different requirements wrt to
> protocol compared to non-journaling fs.

Journaling correctly assumes that block devices call the IO completion
operation with success when the data is really on physical media. All
kernel does the same.

I'll try to explain the different "kinds" of journaling.

The journaling scheme primary objective is to avoid long filesystem
recovery times. But how it does that?

1) data and metadata logging (ext3 < 0.0.3): Strong transactional
guarantees and user data increased reliability. Bad performance if
journal is in the real filesystem disk.

Journaling knows which filesystem updates are not guaranteed to be
complete and consistent. The information about filesystem updates is kept
on the journal until the update completes. The recovery mechanism uses the
journal file to know which parts of the fs probably needs fixing instead
of having to search for them.

The new data and metadata which is being written by a transaction is first
written to the journal file.

*Only* when all IO to the journal file hits the backing storage with
success, the transaction can be commited.

After a transaction is commited, we can start writing the data to the home
locations on disk. When all data and metadata has hitted the home
locations, the transaction is marked finished and the journal entry for
this transaction is freed.

If a crash happens after the commit has reached disk, but before the
finish of the transaction, the recovery mechanism will read the
data/metadata which was stored on journal and write it to home locations,
finishing the transaction.

If an on-going transaction was not committed while a crash happened, the
recovery mechanism will simply remove the transaction from the journal
file. The old data of a transaction is kept unsync until the transaction
commit is done. When commit finishes, we're sure we will not need to use
the old data in recovery anyway.

So if we use protocol B, and the secondary node receives (lets say) all
the blocks of a transaction and acks them to the primary which now will
mark call the IO completion operation.

For the journaling filesystem running at the primary node, its ok to
commit this transaction since all blocks are reported to be on the
journal. And it does that.

The block which represents the commit operation will be sent to the
secondary node and can reach the disk before the transaction blocks are in
the journal. We can crash having a commited but not uptodated transaction
in the journal file of the secondary node which means consistency problem.
In this case, the recovery mechanism will write bad data to the real home
location.

2) Metadata only journaling (reiserfs, newest ext3 supports both
methods, jfs, vxfs, etc): Its a lot faster but it does not increase
user data reliability and there is no strong transactional support.

It guarantees metadata consistency by ensuring that metadata is written to
its home location only after a journal entry for this metadata is commited
in the journal.

With protocol B, the commit problem happens so there is no consistency
guarantee.

> let me sketch my understanding of a scenario. Starting point: drbd
> device is in sync node 1 primary node 2 secondary;
>
> Now, let's assume some write access on the primary and protocol B. This
> gives us a possible time window where 1 has commited the data to disk and 2
> hasn't.

> The data HAS however been received by drbd on node 2.

But it its not synced in the secondary node disk.

> Now, assume a
> failure.
>
> a) node 1 goes down.
> Node 2 doesn't go down, it becomes primary. any data received and acked by
> drbd should be correctly returned by a read request when going primary on
> node 2. So, I'd expect failover to work without risk of corruption in this
> case.

The lack of write guarantee in protocol B will cause what I told up there.
>
> b) node 2 goes down.
> Now we've definitely lost data, node 2 is no longer in sync with node 1
> and node 1 doesn't know about it; the missing data will not be repaired by
> quicksync when node2 comes back up again. This is the risk I take with
> protocol B and sould be the same regardless wether I use a journaling or
> "normal" filesystem.

Who has the most updated data is a completly different issue from the
protocol B problem.

Protocol B problem is that does not guaranteed that data is synced. This
breaks journaling, O_SYNC, raw IO, etc, etc.

> So in my understanding it boils down to the choice between either using
> protocol C + quicksync or protocol B + full rebuild to actually guarantee
> the mirrors stay in sync if one node goes down temporarily.

Again, the protocol issue is different from the "who has good data" issue.

Alan Robertson has a nice solution to the second problem and Luis Claudio
is looking at the implementation.

>
> > > These occured using a CVS version of drbd - I believe your patches are
> > > already included in current CVS code; the tests were run aroun Nov 15 I
> > > don't recall if your patch was in the snapshout I used for the
> > > test. I'll retest with current snapshot to make sure your patches are in
> use.
> >
> > My patch is not applied on drbd CVS yet.
>
> Just to make sure: the correct patch is the one you posted on 10.16.2000
> with a subject "2.2.17 drbd/nbd deadlock problem found", right?

Yup.

>
> > Report your results :)
>
> Testing in progress now... just have to get the messed up scripts from CVS
> into a state where it's actually possible to do actually USE them.

Hi,

> > Report your results :)
>
> Ok, back with first results - all good so far. I'm now running:
>
> Linux 2.2.17
> Alans Pre 2.2.18pre18 patch
> Andreas VM Patch
> Reiserfs 3.5.27
> Drbd Snapshot 0.58 from CVS (2000.12.03)
> your deadlock patches

> I haven't been able to kill the system (yet :-). If I do manage to break
> things again, I'll let you know.

new data point: this remains true for kernels compiled for single processor.
If the kernels (+drbd) are compiled for SMP the secondary system freezes
after a few moments. The systems have only one cpu each; unfortunately I
don't have two real smp systems for testing.

Console messages:
drbd1: it's getting late
drbd1: sending postpone packet!
drbd1: it's getting late

BTW, I get quite a few of these in single processor mode as well;
Switching consoles works, any disk access (regardless wether drbd or another
disk) seems to block; shutdown is no longer possible, reboot via
magic-sysreq works.

the testsystem has 3 drbd devices, all running protocol C and reiserfs.
looks like initial quick-sync runs ok but the secondary system freezes
almost immediately on write to the connected drbd device.

The primary just reports ack timeout & loss of connection and continues
working in disconnected state.

Bye, Martin

"you have moved your mouse, please reboot to make this change take effect"
--------------------------------------------------
Martin Bene vox: +43-316-813824
simon media fax: +43-316-813824-6
Nikolaiplatz 4 e-mail: mb@example.com
8020 Graz, Austria
--------------------------------------------------
finger mb@example.com for PGP public key

On Thu, Dec 07, 2000 at 05:57:16PM +0100, Martin Bene wrote:
> > Linux 2.2.17
> > Alans Pre 2.2.18pre18 patch
> > Andreas VM Patch
> > Reiserfs 3.5.27
> > Drbd Snapshot 0.58 from CVS (2000.12.03)
> > your deadlock patches
...
> new data point: this remains true for kernels compiled for single processor.
> If the kernels (+drbd) are compiled for SMP the secondary system freezes
> after a few moments. The systems have only one cpu each; unfortunately I
> don't have two real smp systems for testing.
>
> Console messages:
> drbd1: it's getting late
> drbd1: sending postpone packet!
> drbd1: it's getting late
>
> BTW, I get quite a few of these in single processor mode as well;
> Switching consoles works, any disk access (regardless wether drbd or another
> disk) seems to block; shutdown is no longer possible, reboot via
> magic-sysreq works.
>
> the testsystem has 3 drbd devices, all running protocol C and reiserfs.
> looks like initial quick-sync runs ok but the secondary system freezes
> almost immediately on write to the connected drbd device.
>
> The primary just reports ack timeout & loss of connection and continues
> working in disconnected state.

This is what I have seen on MP machines too. Protocol C hangs the
secondary after a few writes. FYI, protocol B and A seem not to have
this problem for me. Could you retest with protocol B to confirm?

Thanks

-dg

--
David Gould dg@example.com
SuSE, Inc., 580 2cd St. #210, Oakland, CA 94607 510.628.3380
"As I've gained more experience with Perl it strikes me that it
resembles Lisp in many ways, albeit Lisp as channeled by an awk
script on acid." -- Tim Moore <moore@example.com>,
on comp.lang.lisp

Hi David,
> > the testsystem has 3 drbd devices, all running protocol C and reiserfs.
> > looks like initial quick-sync runs ok but the secondary system freezes
> > almost immediately on write to the connected drbd device.

> This is what I have seen on MP machines too. Protocol C hangs the
> secondary after a few writes. FYI, protocol B and A seem not to have
> this problem for me. Could you retest with protocol B to confirm?

Sure, can do. (... time passes ...)

Yes, I can confirm your report, the tests run fine unsing protocol B;
unfortunately Marcelo convinced me that I should be running protocol C in
conjunction with a journaling filesystem. :-(

Bye, Martin


"you have moved your mouse, please reboot to make this change take effect"
--------------------------------------------------
Martin Bene vox: +43-316-813824
simon media fax: +43-316-813824-6
Nikolaiplatz 4 e-mail: mb@example.com
8020 Graz, Austria
--------------------------------------------------
finger mb@example.com for PGP public key

On Thu, 7 Dec 2000, David Gould wrote:

> On Thu, Dec 07, 2000 at 05:57:16PM +0100, Martin Bene wrote:
> > > Linux 2.2.17
> > > Alans Pre 2.2.18pre18 patch
> > > Andreas VM Patch
> > > Reiserfs 3.5.27
> > > Drbd Snapshot 0.58 from CVS (2000.12.03)
> > > your deadlock patches
> ...
> > new data point: this remains true for kernels compiled for single processor.
> > If the kernels (+drbd) are compiled for SMP the secondary system freezes
> > after a few moments. The systems have only one cpu each; unfortunately I
> > don't have two real smp systems for testing.
> >
> > Console messages:
> > drbd1: it's getting late
> > drbd1: sending postpone packet!
> > drbd1: it's getting late
> >
> > BTW, I get quite a few of these in single processor mode as well;
> > Switching consoles works, any disk access (regardless wether drbd or another
> > disk) seems to block; shutdown is no longer possible, reboot via
> > magic-sysreq works.
> >
> > the testsystem has 3 drbd devices, all running protocol C and reiserfs.
> > looks like initial quick-sync runs ok but the secondary system freezes
> > almost immediately on write to the connected drbd device.
> >
> > The primary just reports ack timeout & loss of connection and continues
> > working in disconnected state.
>
> This is what I have seen on MP machines too. Protocol C hangs the
> secondary after a few writes. FYI, protocol B and A seem not to have
> this problem for me. Could you retest with protocol B to confirm?

David,

In the case you've seen the primary _and_ secondary are SMP ?

On Thu, Dec 07, 2000 at 09:04:25PM +0100, Martin Bene wrote:
> Hi David,
> > > the testsystem has 3 drbd devices, all running protocol C and reiserfs.
> > > looks like initial quick-sync runs ok but the secondary system freezes
> > > almost immediately on write to the connected drbd device.
>
> > This is what I have seen on MP machines too. Protocol C hangs the
> > secondary after a few writes. FYI, protocol B and A seem not to have
> > this problem for me. Could you retest with protocol B to confirm?
>
> Sure, can do. (... time passes ...)
>
> Yes, I can confirm your report, the tests run fine unsing protocol B;
> unfortunately Marcelo convinced me that I should be running protocol C in
> conjunction with a journaling filesystem. :-(

Unfortunately. But we have now estabished a few things:

- it only fails with the SMP kernel, even on a UP (still true?)
- it only fails with protocol C.
- even with all the latest patches it still fails.

Thanks

-dg

--
David Gould dg@example.com
SuSE, Inc., 580 2cd St. #210, Oakland, CA 94607 510.628.3380
"As I've gained more experience with Perl it strikes me that it
resembles Lisp in many ways, albeit Lisp as channeled by an awk
script on acid." -- Tim Moore <moore@example.com>,
on comp.lang.lisp

On Thu, 7 Dec 2000, David Gould wrote:

> On Thu, Dec 07, 2000 at 09:13:51PM -0200, Marcelo Tosatti wrote:
> >
> > In the case you've seen the primary _and_ secondary are SMP ?
>
> Yes, but I don't think that matters. I think that it is only the secondary
> that has the problem, and only protocol C.

With the secondary being UP and with protocol C you can see the problem?

On Thu, Dec 07, 2000 at 09:13:51PM -0200, Marcelo Tosatti wrote:
>
> In the case you've seen the primary _and_ secondary are SMP ?

Yes, but I don't think that matters. I think that it is only the secondary
that has the problem, and only protocol C.

-dg

--
David Gould dg@example.com
SuSE, Inc., 580 2cd St. #210, Oakland, CA 94607 510.628.3380
"As I've gained more experience with Perl it strikes me that it
resembles Lisp in many ways, albeit Lisp as channeled by an awk
script on acid." -- Tim Moore <moore@example.com>,
on comp.lang.lisp

On Fri, Dec 08, 2000 at 02:22:24AM -0200, Marcelo Tosatti wrote:
>
>
> On Thu, 7 Dec 2000, David Gould wrote:
>
> > On Thu, Dec 07, 2000 at 09:13:51PM -0200, Marcelo Tosatti wrote:
> > >
> > > In the case you've seen the primary _and_ secondary are SMP ?
> >
> > Yes, but I don't think that matters. I think that it is only the secondary
> > that has the problem, and only protocol C.
>
> With the secondary being UP and with protocol C you can see the problem?

I see the problem on a 2way SMP secondary, but only with protocol C. If we
are to believe "Martin Bene" <mb@example.com>, the secondary only needs to be
running the SMP kernel, not even to actually have more than one processor.

Martin, is this right, you see the hang even with one processor and the SMP
kernel? Also, did you build drbd with the SMP kernel in place (drbd builds
differently for UP and SMP)?

-dg

--
David Gould dg@example.com
SuSE, Inc., 580 2cd St. #210, Oakland, CA 94607 510.628.3380
"As I've gained more experience with Perl it strikes me that it
resembles Lisp in many ways, albeit Lisp as channeled by an awk
script on acid." -- Tim Moore <moore@example.com>,
on comp.lang.lisp

On Thu, 7 Dec 2000, David Gould wrote:

> I see the problem on a 2way SMP secondary, but only with protocol C. If we
> are to believe "Martin Bene" <mb@example.com>, the secondary only needs to be
> running the SMP kernel, not even to actually have more than one processor.
>
> Martin, is this right, you see the hang even with one processor and the SMP
> kernel? Also, did you build drbd with the SMP kernel in place (drbd builds
> differently for UP and SMP)?

Yes this is right. SMP Kernel on UP System does trigger the hang on the
secondary. And Yes, drbd was built after switching to the SMP
kernel so Makefile.vars can throw in the -D__SMP__ switch.

Just to explain why I'm using an SMP kernel on a UP system: the production
system I want to deploy to is SMP, the test system unfortunately is only
UP.

Bye, Martin