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