[DRBD-user] Re: Another log - primary corruption when secondary comes up

Eugene Crosser crosser at rol.ru
Tue Apr 27 18:08:44 CEST 2004

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


I am putting this on the maillist because I think the answers sould be
interesting to everybody.

On Tue, 2004-04-27 at 15:33, Lars Ellenberg wrote:

> > nfsa2 was working primary, with freshly run fsck and quotacheck.  At the
> > moment when secondary came up and started synchronizing VFS error
> > messages began appearing in the log.  And yes, fsck and quotacheck find
> > plenty of errors on such filesystem.
> > 
> > Apr 27 12:03:09 nfsa1.mail.back kernel: drbd0: size = 214165504 KB
> > Apr 27 12:03:10 nfsa1.mail.back kernel: drbd0: 0 KB marked out-of-sync by on disk bit-map.
> > Apr 27 12:03:10 nfsa1.mail.back kernel: drbd0: Found 6 transactions (324 active extents) in activity log.
> > Apr 27 12:03:10 nfsa1.mail.back kernel: drbd0: Marked additional 1052672 KB as out-of-sync based on AL.
> > Apr 27 12:03:10 nfsa1.mail.back kernel: drbd0: Connection established.
> > Apr 27 12:03:10 nfsa2.mail.back kernel: drbd0: Connection established.
> > Apr 27 12:03:10 nfsa2.mail.back kernel: drbd0: Resync started as target (need to sync 2450904 KB).
> > Apr 27 12:03:10 nfsa1.mail.back kernel: drbd0: Resync started as source (need to sync 2450904 KB).
> 
> this is the problem.
> see, you say you have the nfsa2 primary.
> but on connection, DRBD decides that the primary node shall become sync
> *TARGET*, so it gets overwritten with the BAD data from nfsa1 UNDERNEATH
> the file system, which obviously corrupts the contents :(

So, how exactly drbd decides which node to make syncsource and which
synctarget?  In 0.6 it was pretty easy: primary is source.

Is it wise at all to allow primary be a target?  Will the application be
happy if the data is magically modified?  How to avoid problems?

If the "sourceness" is defined by some "generation number" in the
metadata, I can easily see a scenario where this may become a problem.

If this is discussed somewhere on www.drbd.org, please point me there.

Thanks
Eugene
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20040427/4c75aa3d/attachment.pgp>


More information about the drbd-user mailing list