Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Shouldn't you be doing you fs operations on the drbd device? If you did a growfs on the raw device - that would clobber the metadata at the end of the device that drbd uses. Tom Davidson wrote: > I've just added a second hard disk to my Gentoo cluster nodes running a DRBD > 0.7.25 backing store. I extended my LVM (2.x) volume group and extended my > logical volume by 230GB: > # pvcreate /dev/hdc3 > # vgextend bigvg /dev/hdc3 > # lvextend -L+230g /dev/bigvg/store > > > Then I mounted up my newly extended LV and saw that it's space was still > showing as 220GB as expected. I performed an online resize as required for > JFS and the space increased to 450GB as expected, and all my content was > present. I unmounted it ready for DRBD: > # mount -t jfs /dev/bigvg/store /store > # df -h /store > # mount -o remount,resize /store > # df -h /store > # umount /store > > > DRBD started up fine, however, when I tried to mount the drbd device I got > # /etc/init.d/drbd start > # cat /proc/drbd > [snip] > # drbdadm primary samba > # mount -t jfs /dev/drbd1 /store > mount: wrong fs type, bad option, bad superblock on /dev/drbd1, > missing codepage or other error > In some cases useful info is found in syslog - try > dmesg | tail or so > dmesg shows the following message: > attempt to access beyond end of device > drbd1: rw=16, want=943652880, limit=461373440 > which might suggest that the drbd device is still seeing the old size > > So I tried resizing (which incidently I didn't need to do in my identical > VMware test environment): > # drbdadm resize samba > But I got the same result. I then tried fscking the filesystem and it > suggested it was totally shafted: > # jfs_fsck -n /dev/drbd1 > jfs_fsck version 1.1.8, 03-May-2005 > processing started: 9/23/2007 8.29.9 > The current device is: /dev/drbd1 > Superblock is corrupt and cannot be repaired > since both primary and secondary copies are corrupt. > > CANNOT CONTINUE. > > But the underlying LV definately still fine as I can make the drbd resource > secondary again, fsck and mount up /dev/bigvg/store ok and all the content > is still there. > > So have I done something wrong in my process, and/or how can I fix the drbd > resource so that it sees the new correct LV size. I should still be able to > recover by reformatting the filesystem and copying the data over from the > other node, but rather not have to, and I'm likely to have to do this again > in the future (and also for the other LVs in the cluster) so I would like to > know how to get it right next time. > > Tom > > _______________________________________________ > drbd-user mailing list > drbd-user at lists.linbit.com > http://lists.linbit.com/mailman/listinfo/drbd-user >