[DRBD-user] Tracking down sources of corruption examined by drbdadm verify

Szeróvay Gergely gergely.szerovay at gmail.com
Thu May 8 13:05:44 CEST 2008

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


I've done further test with ReiserFS.

I have a script callad md5_list. It lists all files/subdirs/links in a
directory recrusively, in the following format:

file name with full path - file type - md5sum of  file (if it's real
file) - file size - owner/group/acc. rights - mtime

I modified my test process. At the beginning, node1=primary,
node2=secondary node.
Step 1-7 it's the same as in my previous reply.
1. node1: mkfs on drbd0
2. node1: mount drbd0 to /mnt/test
2. node1: extract the snapshot (120MB) to /mnt/test
3. node1: start Mysql daemon, datadir = /mnt/test
4. node1: replay the SQL file (90MB) with the Mysql client
5. node1: stop Mysql daemon
6. node1: umount /mnt/test
7. node1: drbdadm verify drbd0, wait until it finished

8. node1: drbdadm disconnect drbd0
9. node1: mount drbd0, generate the list with md5_list
10. node2: drbdadm primary drbd0
11. node2: reiserfsck drbd0
12. node2: mount drbd0, generate the list with md5_list

13. compare the list from node1 and node2 with diff

14. node2: umount drbd0, drbdadm secondary drbd0, drbdadm invalidate
drbd0, drbdadm connect drbd0
15: node1: drbdadm connect drbd0

I've made 5 runs with this test. I've got 12, 6, 10, 6, 9 oos blocks.
The reiserfsck never found problems on node2, and the generated
md5_lists were always identical on both node. It means that the
contains of the filesystem was identical on both nodes, the oos blocks
were in the unused space.

So this test confirmed that the oos blocks are "out of filesystem" blocks.



More information about the drbd-user mailing list