
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">

<HTML>

<HEAD>

  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">

  <META NAME="GENERATOR" CONTENT="GtkHTML/3.12.0">

</HEAD>

<BODY>

Hi list,<BR>

I had one of my HA systems, running drbd 8.0.1, issue an error on its drbd0 device (see title). We recently resized the underlying partition using gparted to include the partition immediately following it (verified that the new, larger partitions were identical, and ran the command to fix the meta-data, suggested when drbd was restarted). We did this on both systems, and everything seemed OK for a few days. This morning we got the error, heartbeat detected it, and migrated resources to the other system, no problem. I took drbd down on both systems, mounted and set primary drbd0 on the system with the issue, and did an fsck -fvn /dev/drbd0 on it (unmounted). I get the following:<BR>

<BR>

The filesystem size (according to the superblock) is 29288495 blocks<BR>

The physical size of the device is 29287592 blocks<BR>

Either the superblock or the partition table is likely to be corrupt!<BR>

<BR>

So, I then ran fsck without the -n to correct. Now, drbd seems to be completely hosed up. If I do a ./drbd start, the system locks up. If I do the drbdadm adjust pgsql, it locks up the system too. I went as far as to shutdown drbd, remove the kernel module, delete the sda5 partition and recreate it, starting over, and it still locks up the system when I try to bring up drbd. What I'd like to do is fix the issue on this system, and let it get back in sync with the other system. So 1) How do I get drbd back and functioning on the system where the issue occurred?, and 2) Do I need to do anything to the system that is currently running OK (due to the partition resize, etc)?<BR>

<BR>

Thanks,<BR>

Doug Knight<BR>

WSI Corp<BR>

Andover, MA 01945

</BODY>

</HTML>