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