Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
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.