Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Fri, Sep 12, 2008 at 09:08:19AM -0700, Chris Miller wrote:
>
> I've got a drbd partition that recently started logging errors after
> trouble free operation for about a week :
>
> Sep 10 22:57:27 ha2 kernel: attempt to access beyond end of device
> Sep 10 22:57:27 ha2 kernel: drbd0: rw=0, want=6365608736,
> limit=1381325576
> Sep 10 22:57:27 ha2 kernel: attempt to access beyond end of device
> Sep 10 22:57:27 ha2 kernel: drbd0: rw=0, want=14950835016,
> limit=1381325576
> Sep 10 22:57:27 ha2 kernel: attempt to access beyond end of device
> Sep 10 22:57:27 ha2 kernel: drbd0: rw=0, want=13983521568,
> limit=1381325576
> Sep 10 22:57:27 ha2 kernel: attempt to access beyond end of device
> Sep 10 22:57:27 ha2 kernel: drbd0: rw=0, want=6365080488,
> limit=1381325576
> Sep 10 22:57:27 ha2 kernel: attempt to access beyond end of device
>
> The setup was pretty straight forward and I did not specify any size
> when creating the drbd device on LVM or ext3 filesystem. The
> physical disk is 750GB :
>
> # fdisk -l /dev/sda
>
> Disk /dev/sda: 749.9 GB, 749988741120 bytes
> 255 heads, 63 sectors/track, 91180 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
>
> Device Boot Start End Blocks Id System
> /dev/sda1 * 1 25 200781 83 Linux
> /dev/sda2 26 91180 732202537+ 8e Linux LVM
>
> # lvscan
> ACTIVE '/dev/VolGroup00/LogVol00' [39.06 GB] inherit
> ACTIVE '/dev/VolGroup00/LogVol02' [658.72 GB] inherit
> ACTIVE '/dev/VolGroup00/LogVol01' [512.00 MB] inherit
do
cat /proc/partitions
lvs --units k -o name,vg_name,kernel_major,kernel_minor,size
and, please do NOT use --units K.
but --units k.
see man lvs.
also, do
tune2fs -l /dev/drbd0 |
awk -F: '/^Block count:/ { bc = $2; };
/^Block size:/ { bz = $2; };
END { print bc, bz ; print bc*bz/1024 }'
> The major alarm bell for me is that lvscan says the size is 658.72
> GB, but the volume group and ext3 filesystem is reported by fdisk as
> 690662788.
> Did ext3 really create a filesystem beyond the limits of
> the drbd device,
unlikely.
> or is this just a GB/GiB thing?.
690662788 / 1024 / 1024 == 658
so, yes, this latter thing aparently is a GB GiB thing,
as the size given in drbd.conf is GiB.
> If the filesystem was not written correctly, how did this happen when
> no size was ever specified? Going from memory/history, I roughly did
> the following :
>
> drbd.conf snippet :
>
> resource data {
> on ha1 {
> device /dev/drbd0;
> disk /dev/mapper/VolGroup00-LogVol02;
> address 10.0.0.1:7789;
> meta-disk internal;
> }
> on ha2 {
> device /dev/drbd0;
> disk /dev/mapper/VolGroup00-LogVol02;
> address 10.0.0.2:7789;
> meta-disk internal;
> }
> }
>
> Commands :
>
> # drbdadm create-md data
> # mkfs.ext3 /dev/drbd0
my guess is that you did NOT do mkfs.ext3 /dev/drbd0,
but you did mkfs.ext3 /dev/mapper/VolGroup00-LogVol02.
the tune2fs | awk should give a hint.
> Second question is, if it's broke, how do I fix it? Seems like I
> would need to reconfigure the other server's partition, resync the
> data, and repeat on the other server. But how can I insure the
> partition is sized correctly?
take drbd down.
on one server (preferable the one that has been primary last):
force an fsck directly on the LV
resize2fs 690662788k
drbd up again.
force full sync.
--
: Lars Ellenberg
: LINBIT HA-Solutions GmbH
: DRBD®/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks
of LINBIT Information Technologies GmbH
__
please don't Cc me, but send to list -- I'm subscribed