Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Tue, Jun 21, 2011 at 11:51 PM, Lars Ellenberg wrote: > On Tue, Jun 21, 2011 at 05:55:24PM +0200, Gianluca Cecchi wrote: >> hello, >> using drbd 8.3.8 in CentOS 5.6 as provided by extra repo. >> testing/simulating condition when secondary is taken down and some of >> its data are modified before restart it... >> (or you want to verify that if any problem/bug have modified them, you >> come back to safety when you restart the secondary) [snip] >> >> 3) mount backing device on secondary > > Do not bypass DRBD. > > Well, of course you can. > > But if you do, don't blame DRBD for not keeping track of your doings. Thanks for your time. Certainly it is not my intention to bypass DRBD. In fact in my e-mail I tried to clarify that it was a simulation of changed data before resync. My example was the deletion of a file, but in general it could be something else, eventually not human driven... but caused by a fault condition or something else... My intent was to understand the correct approach in case of doubt about secondary backing device access in the mean time when disconnected (for example if you have not complete control of the other side of the DRBD link, from an IT organization point of view...) Are both the below steps equivalent from a result effect point of view? What would you suggest/advice in such case? a) drbdadm verify r0 drbdadm disconnect drbdadm connect As the verify action immediately comes back to prompt, is there a way to automate the three steps in one atomic operation other than monitor /var/log/messages or output of "cat /proc/drbd"? b) drbdadm invalidate-remote r0