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 :
_______________________________________________
drbd-announce mailing list
drbd-announce@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-announce
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 :
_______________________________________________
drbd-announce mailing list
drbd-announce@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-announce