[DRBD-user] Info at /proc/drbd diverges on the amount of data to be sync'ed

Marcelo Pereira marcelops at gmail.com
Wed Apr 4 19:45:22 CEST 2012

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


Hi Matt,

*> node1:  [>....................] sync'ed:  0.2% (6858868/*6869920*)M
> > node0 says 6,869,922, and node1 says 6,869,920.
> *
> *>
> > I have tried to sync this box a couple of times already, and it always
> gets
> > stalled at 100%.
>
> *
> *This doesn't seem right.  What does "blockdev --getsize" return on the
> backing
> device for both machines?  This should generally return the same number,
> and a
> number that's smaller than the output of "blockdev --getsize /dev/drbdX" on
> the primary machine unless you're using external metadata.*
>

I put the node0 as primary, and executed:

[~]# blockdev --getsize /dev/drbd0

Then, put it back as secondary, went to node1, put it as primary and
executed the same above. The output was exactly the same on both:

31248970352

 *I see both machines are set to Secondary.  Why is that?*


As I said, I have been trying to sync this box for a long time, and I
always get stalled at 100%. This time, I just tried to:

   - umount the unit (to prevent any data modification)
   - set both to secondary (to prevent anything trying to mount it)
   - sync without touching the content of the device.

* Is there a filesystem on this DRBD device?*


Yes!! There is!! It's a 16Tb device, with 7Tb of data in it. I had just
transferred 6Tb of data to the primary node, last week. (I mean, the
secondary node was down, but I transferred the data to the primary anyway).
My data is on the primary, and I can't get the secondary to sync.

I have already tried to discard the secondary, and force a overwrite from
the primary to the secondary. No success, though.


> *If there is, there may be stupid things going on if the
> filesystem is larger than one machine's backing device.  If there isn't a
> filesystem on the device yet, you may be able to get away with just
> "drbdadm
> resize" on the resource--that should shrink the DRBD resource to (size of
> smallest device - internal metadata space) and prevent weirdness in the
> future.*
>

How can I fix/shrink it without losing the data in it??

Thanks,
Marcelo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20120404/d5f4ccd8/attachment.htm>


More information about the drbd-user mailing list