Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Thu, Feb 14, 2008 at 10:07:39AM -0500, Doug Lochart wrote:
> > > I am using DRBD to mirror a 1 terrabyte device. I will be syncing
> > > over a gigabit switch so I assume I can use 100M to 150M as a rate
> > > safely. There will be other traffic on the switch. However I do not
> > > seem to understand how the al-extents parameter is used. Most
> > > examples leave it set to 257 and that is good for an active set of 1
> > > Gig. Could someone explain what the active set implies AND what are
> > > the pros/cons of increasing the active set size or do I need to woory
> > > about.
> >
> > please read
> > http://www.drbd.org/fileadmin/drbd/publications/drbd8.linux-conf.eu.2007.pdf
> >
> Forgive me if I am obviously too stupid to understand but I did read
> that document and it did not help. It makes no mention of the
> parameters in question nor enough information for me to relate the
> information in the document to drbd.conf file entries.
>
> I can understand (not really) but I can accept not being offered a
> high level and simplified explanation of my questions. I do ask
> however help on correlating the config file parameters in question to
> the contents of the this document.
>
> To others I would accept a high level synopsis of what the parameters
> affect and how to use them to tune my replication. Armed with a high
> level view I hope to be able to correlate them back to the technical
> details on this document.
ok, sorry.
section 6 explains the problem of finding which blocks might have been
modified independently during different degraded situations.
6.1 explains the easy part, where we have just a network hickup:
we can use the in-memory dirty-bitmap on the Primary.
6.2 explains why the bitmap alone does not suffice when we think of
Primary node crash.
6.3 argues against synchronous "write intent bitmap writes"
6.4 explains what we do to reliably keep track of the
target blocks of in-flight IO, while minimizing
the frequency of housekeeping meta data transactions.
it summarizes:
The number of slots in the activity-log is tunable
[this is the al-extents configuration parameter you asked for],
the trade-of is larger activity-log, less frequent meta data
transactions, less likely to introduce maximum latency because of
activity-log starvation, but also longer minimum resync time after
Primary crash.
say you have 2.5 TByte of storage.
|-- 2.5 TB of storage ---------------------------------------------|
|- 4MB -|- 4MB -|-~~ // ~~-|- 4MB -|- 4MB -|- 4MB -|- 4MB -|- 4MB -|
0 1 extent numbers .... 655356 655357 655358 655359
you have 655360 extents/areas/regions/whatever of 4MB each.
the al-extent parameter tunes how many of them may be target of
in-flight writes at the same time.
you set al-extents = 7
you have a set of
[ 0, 1, 2, 17, 35, 270, 87 ] in the activity log.
you want to write to somewhere in 37, which is not in the al.
so you wait for any of the regions in the set to become unused,
put that region out of the active set, put the 37 into the active set,
and write that transaction to disk, which takes some time.
only after that has happened, the original write to the 37 extent
may continue.
if a crashed primary comes up again, the active set at the time of the
crash will be reconstructed from these meta data transactions (the
on-disk activity log), and all bits corresponding to any active set will
be dirtied (reason given in section 6.2).
so again:
you go up with al-extents, you have less frequent meta data
transactions, less frequently interruption of your IO stream
for it, you less frequently introduce this additional latency.
but if your primary crashes, it has to resync all extents that have been
in the active set, you have to resync more if the set is larger.
does that help at all?
--
: Lars Ellenberg http://www.linbit.com :
: DRBD/HA support and consulting sales at linbit.com :
: LINBIT Information Technologies GmbH Tel +43-1-8178292-0 :
: Vivenotgasse 48, A-1120 Vienna/Europe Fax +43-1-8178292-82 :
__
please use the "List-Reply" function of your email client.