[DRBD-user] DRBD attempts to access beyond end of device

Lars Ellenberg lars.ellenberg at linbit.com
Thu Feb 28 19:56:53 CET 2008

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

On Thu, Feb 28, 2008 at 12:29:05PM -0500, Todd Denniston wrote:
> Nate Seif wrote, On 02/28/2008 11:12 AM:

>>>>>> Feb 26 08:21:46 <hostname> attempt to access beyond end of device
>>>>>> Feb 26 08:21:46 <hostname> drbd0: rw=1, want=211992584, limit=211986944
>>>>>> Feb 26 08:21:46 <hostname> Buffer I/O error on device drbd0, logical block 26499072

>>>>>> Any ideas, tips, help, etc. is much appreciated. Thank you -
>>>>> let me guess:
>>>>> you did mkfs /dev/sda1, not mkfs /dev/drbd0?
>>>>> well, you screwed up.
>>>> I did NOT mkfs on /dev/hda4. (I have DRBD running on a pair of IDE/PATA
>>>> disks and no SATA drives in either system.)
>>>> I partitioned my disks with fdisk. I have identical drives with
>>>> identically sized partitions. I compiled the DRBD module, started DRBD,
>>>> mounted /dev/drbd0 (not /dev/hda4), and formatted drbd0 with an ext3
>>>> file system on the primary only after I got DRBD up and running months
>>>> ago.
>>> please do
>>>      tune2fs -l /dev/mapper/vg00--bk1-root |
>>>     grep -e ^Block.count: -e ^Block.size:
>> I do not have RAID on either system and /dev/mapper does not exist on  
>> either machine. I have a single, identical hard drive in each system  
>> where /dev/hda4 is the partition DRBD uses. Can I change the tune2fs  
>> command you suggested above to get the bytes my ext3 FS thinks it's  
>> occupying?
> You should be able to...
> please run
> tune2fs -l /dev/hda4 |
>      grep -e ^Block.count: -e ^Block.size:
> or better
> tune2fs -l /dev/drbd0 |
>      grep -e ^Block.count: -e ^Block.size:
> Lars, was there a reason you sent Nate after something other than /dev/drbd0 ???

If I was mean I could pretend I was checking on something.
but actually I was just pasting my command line.

it is allowed, and strongly recommended, to check plausibility of (not
only) my posts, and [censored]. ;)

all of you who have this "access beyond end of device" problem with
some file system on drbd with internal meta data.
I did this ascii art several times meanwhile, but here is it again:

|-- usable area with drbd and internal meta data --|-IMD-|
|-- real device -----------------------------------------|

IMD is "internal meta data".
once created, it is fixed size.
with drbd 0.7 it was fixed 128MB.

with drbd 8.0 it is approximately

[total storage of real device]/4/8/512/2 rounded up,
+36k, rounded up to the next 4k.


> # grep -e hda4 -e drbd0 /proc/partitions
>    3     4  105996744 hda4
>  147     0  105993472 drbd0

ceil(105996744 kB / 32768) == 3235 kB
                           +    36 kB
                           == 3271 kB
               4k  aligned == 3272 kB

105996744 kB - 3272 kB == 105993472 kB.


if you did mkfs /real/device,
then later mount through DRBD,
the file system either recognized size mismatch
in superblock vs. actual block device size
on the spot and refuse to mount
(xfs does this, iirc).

or the file system mounts alright because it skips the check for block
device size (it is ok for a file system to assume that its superblock
contains valid data; ext3, at least certain version of it, aparently do
this) and then thinks it could use the now not available space which is
occupied by IMD.

there are various ways to find out what your file system thinks about
the usable space it occupies. for ext3, the above given
"tune2fs | grep" trick is one way that is readily availabe.

as long as the file system does not want to use that area, it won't
notice.  if the file system eventually decides to use that area, whops,
surprise, it gets an access beyond end of device error.

when the file system will start using that area is nearly impossible to
pretict.  so it may appear to work fine for month, and then suddenly
break again and again.

this is not a problem with drbd.
it is a problem with abusing drbd.

well, until someone proves me wrong, of course, and gives me an easy to
reproduce test case, where a straight forward mkfs /dev/drbd0 results in
a file system is bigger than the usable size of drbd.

: Lars Ellenberg                           http://www.linbit.com :
: DRBD/HA support and consulting             sales at linbit.com :
: LINBIT Information Technologies GmbH      Tel +43-1-8178292-0  :
: Vivenotgasse 48, A-1120 Vienna/Europe     Fax +43-1-8178292-82 :
please use the "List-Reply" function of your email client.

More information about the drbd-user mailing list