Please let me answer myself, in case others look for the same answers later.
The following is only assumptions however, so please somebody correct me if I'm wrong.

Sometime we have big activity spikes, like someone writing a 100GB video work. The network is slow so we may want to let the secondary node fall behind, and we may use drbd-proxy I gave the new features in v8.3.10 a try without drbd-proxy, and I humbly admit I don't get the whole picture, so please let me ask a few questions.

First, is drbd-proxy required if we want to use the new congestion settings in v3.8.10?
From what I understand, it is not required, but the congestion features are mostly useless without it.
If it's not required, then I wonder if it would be useful in our setup. With video data, compression won't help, and when I push large files to the drbd resource, "free" tells me the overall buffers get as large as 7GB. What more does drbd-proxy do?
The 7GB were actually not at all in DRBD's buffers, but in the kernel's dirty pages - we are used to having a very high vm.dirty_ratio on storage servers, to use lots of RAM as write cache. From what I can tell, drbd-proxy would provide the following bonus vs dirty pages: - smoother behavior: insensitive to sync() and various kernel optimizations trying to keep the dirty page count low
- compression
Another point that I don't get is how drbd uses the "congestion-fill" parameter. If I set it low (like 1K), the secondary node falls behind as soon as there is write activity, as I expected. But if I set it to 1G and I rsync a 10GB file full of zeros to the FS on the resource, the secondary node never falls behind and rsync slows down to the network speed. Am I doing it wrong?
Actually the TCP buffer never gets bigger than a few MB, so my guess is that any value of congestion-fill bigger than that will never make the secondary node fall behind. I don't see the point in allowing values as big as 10GB, so I may still be missing something.

Lionel Sausin - Numérigrahe SARL.

_______________________________________________
drbd-user mailing list
[email protected]
http://lists.linbit.com/mailman/listinfo/drbd-user
  • [DRBD-us... Lionel Sausin
    • Re:... Lionel Sausin, de la part de l'équipe informatique Numérigraphe
      • ... Lars Ellenberg
        • ... Lionel Sausin, de la part de l'équipe informatique Numérigraphe

Reply via email to