[DRBD-announce] drbd-0.7.8.tar.gz

[Philipp Reisner]

Hi

0.7.8 (api:77/proto:74)
-----
 * Fixed a bug that caused the syncer to starve on devices 
   bigger than 2 TB on 32bit systems (=CONFIG_LBD).
 * Made online resizing actually work. Now it makes a lot
   more sense to put DRBD on top of LVM.
 * Made the user dialog to work on RedHat based distributions.
 * A small optimization that improves the performance of the 
   syncer when woking with IBM's ServRaid Controllers (ips).
   May have a positive effect with other Controllers as well.
 * Made epoch_size atomic. This removes a SMP race condition that
   could lead on some Xeon CPUs to an ASSERT printk, but did no other
   harm than printing messages to the syslog
 * Fixed write_gc.pl to work with the perl version delivered
   with RHAS3.
 * Made the initscript to abort if one of the setup commands fails.

It is always amazing that after drbd-0.7 has been the stable 
release for such a long period of time, that there are still
new issues to discover and to resolve. Here are some SVN
log entries : 

----
Well one day after the 0.7.7 release and again an important
bug fix :(

 On 32Bit systems with CONFIG_LBD set, DRBD fails to calculate
 the right sectornumber from the bitnumber. Only affects devices
 bigger than 2 TB.

 Symptom: If you do a resync and suddenly the progress of the 
          resync stops, (or it never moves at all), but you can 
          see that DRBD gereates IO.
          After the expected resync time IO stops, but the
          progress indicator is still at its position.

DRBD simply resynced the wrong blocks, and since no bit
in the bitmap were cleared, no progress of the resync.
----
I realized that on RHAS3 systems (and probabely all other RedHat
based and related distributions) drbdadm's user dialog
was not displayed in the boot process.
RedHat's rc script redirects all output of init scripts to
the Logfiles exclusively!! 
If drbdadm detects this (by using isatty(stdin)) it prints
a warning and does the user dialog on /dev/console
----
* On this brand new dual Xeon system the counting of
  epoch_size is broken. Probabely this revision of Xeons
  is doing memory access reordering more agressive than
  previous versions. Converting epoch size form 
  int to atomic_t solved the issue.
* When reading from an IBM-ServRaid controller (ips), 
  we need to call run_disk_queue() from time to time
  to get sane performance of it.
* On this RHAT3 box the write_gc.pl program failed
  to correctly write DRBD's magic number. 
  (probabely a bug in the perl version included 
   with RHAT3.)
----

-Philipp
-- 
: Dipl-Ing Philipp Reisner                      Tel +43-1-8178292-50 :
: LINBIT Information Technologies GmbH          Fax +43-1-8178292-82 :
: Schönbrunnerstr 244, 1120 Vienna, Austria    http://www.linbit.com :