Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Tue, Nov 17, 2009 at 5:27 PM, Brian Marshall <brian at netcents.com> wrote:
> Hello,
>
[snip]
> I installed the disks at the remote location and brought up the array in
> active-active synchronous mode.
[snip]
> so I did an invalidate-remote
> from the local node and watched in horror as it tried to re-sync the
> entire array.
[snip]
from user guide:
invalidate Forces DRBD to consider the data on the local backing storage
device
as out-of-sync. Therefore DRBD will copy *each and every
block* over
from its peer, to bring the local storage device back in
sync.
invalidate-remote This command is similar to the invalidate command,
however, the
peer's backing storage is invalidated and hence rewritten
with the data
of the local node.
So DRBD is simply doing what it is asked to do...
Probably to test you could use "secondary" command for the peer instead of
invalidate, then write to the only-remained primary and then re-run primary
on the peer.
but I'm not using ocfs2 and I'm not sure abut ocfs2 DLM behaviour/messages
when secondary command is issued on the peer and how/if to recover if in the
mean time you write also to the peer node fs.....
For sure, chapter 13 of the udrbd user guide would help... '-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20091118/24463d94/attachment.htm>