Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi!
Yes, that should do the trick. However, ot be on the safe side and also
check if the culperit might be the RAID controller underneath it aoud make
sense to trigger a full resync by disconnecting on the Secondary (drbdadm
disconnect resourcename), invalidating (drbdadm invalidate resourcename) on
the secondary and then reconnecting (drbdadm connect resourcename). After
the ensuing resync is finished run another verify. If you get OOS blocks
again, chances are you are writing nonsense to the disk.
IIRC DRBD checks the integrity of the transmission then data intrgirity
checking is active, but not the actual blocks on disk. there it relies on
the underlying layers of the storage subsystem to actually write the data
as it was transmitted. A cronjob runing a verify once every while and
another one checking for any OOS blocks (parsing /proc/drbd) and triggering
a disconnect/reconnect if any are found, might be a good idea. Maybe
someone from LINBIT can comment on this and come up with confirmation or a
better solution. Ideally OOS blocks would be fixed automatically with the
option todisable this function using the config.
Mit freundlichen Grüßen / Best Regards
Robert Köppl
Customer Support & Projects
Teamleader IT Support
KNAPP Systemintegration GmbH
Waltenbachstraße 9
8700 Leoben, Austria
Phone: +43 3842 805-322
Fax: +43 3842 82930-500
robert.koeppl at knapp.com
www.KNAPP.com
Commercial register number: FN 138870x
Commercial register court: Leoben
The information in this e-mail (including any attachment) is confidential
and intended to be for the use of the addressee(s) only. If you have
received the e-mail by mistake, any disclosure, copy, distribution or use
of the contents of the e-mail is prohibited, and you must delete the e-mail
from your system. As e-mail can be changed electronically KNAPP assumes no
responsibility for any alteration to this e-mail or its attachments. KNAPP
has taken every reasonable precaution to ensure that any attachment to this
e-mail has been swept for virus. However, KNAPP does not accept any
liability for damage sustained as a result of such attachment being virus
infected and strongly recommend that you carry out your own virus check
before opening any attachment.
Felix Frank
<ff at mpexnet.de>
Gesendet von: An
drbd-user-bounces Christian Hammers
@lists.linbit.com <chammers at netcologne.de>,
Kopie
drbd-user
07.01.2014 17:11 <drbd-user at lists.linbit.com>
Thema
Re: [DRBD-user] proto c - corrupt
files - directories missing
Hi,
wouldn't a simple disconnect/reconnect do the trick?
After the handshake, drbd will want to sync all blocks with non-zero
bits in the bitmap.
HTH,
Felix
On 01/07/2014 04:51 PM, Christian Hammers wrote:
> Try "drbdadm invalidate clusterdb_res" on your *secondary* node.
> This will start a complete resync from the primary node and
> copies every block whose checksum mismatches. Can take some hours,
> though.
_______________________________________________
drbd-user mailing list
drbd-user at lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user