[DRBD-user] What causes nodes to become out-of-sync?

Jeffrey Froman tcijf at olympus.net
Wed Jul 23 21:13:35 CEST 2008

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


On Tuesday 22 July 2008 10:54:32 am Lars Ellenberg wrote:
> > > do you use tcp checksum offloading?
> > > any other tcp offloading?
<snip>
> ethtool -k ethX

"ethtool -k eth2" output is as follows:

Offload parameters for eth2:
Cannot get device udp large send offload settings: Operation not 
supported
Cannot get device generic segmentation offload settings: Operation not 
supported
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
udp fragmentation offload: off
generic segmentation offload: off

So it looks like we are using some offloading, and that it's possible 
to adjust these settings via ethtool.

> the better "end-to-end" your checksums are,
> the more likely they will detect transfer errors.
>
> so we have that data-integrity-alg in drbd, which puts a
> drbd-to-drbd checksum on the data

Thanks for the clear and detailed explanation. Do I understand 
correctly that using data-integrity-alg at the drbd layer is still 
the most reliable checksum, regardless of tcp offloading? In other 
words, is there any reason to adjust offloading settings if 
data-integrity-alg is enabled?

Also, do I understand correctly that failing hash values cause a 
packet (or block?) to be invisibly re-sent? Or is some other action 
required in the event that a hash comparison fails?


Thank you,
Jeffrey





More information about the drbd-user mailing list