[DRBD-user] diskless on purpose

[Thomas Keppler]

Hi Pierre-Philipp,

Yes, Protocol C would be the most suitable here. 

It means that the DRBD volume acknowledges the write after an actual write through on all diskful nodes has happened.

--
Best regards
Thomas Keppler

> Am 15.12.2020 um 11:03 schrieb Pierre-Philipp Braun <pbraun at nethence.com>:
> 
> 
>> 
>> So did you define an address? :)
> 
> Sorry, I was baffled with the way DRBD node communicate, and mistaken a listening port with an SCSI target.  It works!  It's pretty cool)
> 
> I've tried with Protocol A and I could also mount a resource on node3 indeed.  Hmm but what's the logic behind such a setup?  As the primary node here is diskless, the data is really unsecured and not written anywhere, until it reaches the secondary nodes, right?
> 
> If I wanted to use that diskless trick, to make the resources available across the whole cluster farm, I would probably have to use Protocol C instead, in view not to loose any data in case of a node crash, correct?
> 
> BTW I noticed some misleading message on the diskless node while the initial sync was on-going between the two other nodes.  Not sure it's a bug, but I mention it for the record.
> 
> r1 role:Secondary
>  disk:Diskless
>  lin1 role:Primary
>    peer-disk:UpToDate
>  lin2 role:Secondary
>    peer-disk:Inconsistent resync-suspended:peer
> 
>> create the resource on node 1 and 2 and on 3 diskless. And then look at
>> the resource files LINSTOR generated. That will not spoil you too much
>> :).
> 
> When creating a resource with --drbd-diskless, a totally useless and empty resource gets created.  So it's much worse than doing it manually.  I don't understand how to use that linstor option correctly, to begin with.
> 
> Thank you
> _______________________________________________
> Star us on GITHUB: https://github.com/LINBIT
> drbd-user mailing list
> drbd-user at lists.linbit.com
> https://lists.linbit.com/mailman/listinfo/drbd-user