[DRBD-user] error when rezising a JFS volume

David Stanaway david at stanaway.net
Sun Sep 23 20:56:01 CEST 2007

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.
> 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

More information about the drbd-user mailing list