Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a Debian Xen DomU which has a DRBD mounted partition. I needed to resize this partition from 46G to 50G. I did the following:

  • Stopped DRBD on the secondary node: /etc/init.d/drbd stop
  • Increased the underlying LVM dist to 50 GB: lvresize -L 50G /lvm/device
  • Started DRBD again and waited for the disk to sync: /etc/init.d/drbd start
  • Switched Primaries. And performed the same on the other node.
  • Stopped drbd on the now secondary DRBD node: /etc/init.d/drbd stop
  • Increased the underlying LVM: lvresize -L 50G /lvm/device
  • Started DRBD again and waited for the disk to sync: /etc/init.d/drbd start
  • On both nodes issued: drbdadm resize drbd-device
  • On the primary node issued a: resize2fs /dev/drbd0

I get this response:

$ resize2fs 1.40-WIP (14-Nov-2006)
The filesystem is already 12058624 blocks long.  Nothing to do!

Using fdisk, both the drbd0 and the sda device drbd is using report the size of the device as 49392123904. Which is consistent with what resize2fs is saying. (12058624x4096 [blocksize]).

My issue is that df isn't reporting the change to the disk size.

$ df -B 4096
/dev/drbd0            11869420  11155652    110968 100% /data

I have done this process before and had no issues. Is there something I am missing?

share|improve this question
How was it mounted? Also can you try df with --sync not sure what that does but if it is there maybe there is a reason! Also what does fdisk say? – Joshua D'Alton Mar 17 '11 at 8:14
This all sounds right. Does lvs report the expected size? – Insyte Mar 19 '11 at 6:16
perhaps remounting the partition might help? – malcolmpdx Mar 23 '11 at 23:41
I never figured this out. * LVS was reporting the correct size of 50G. * Unmounting and remounting the partition didn't help. * Full reboot of these DomU's also didn't solve the issue. It felt quite buggy that this wasn't working right and we were due for a hardware upgrade so I have since replaced these with 2 new CentOS machines and this is no longer an issue for me. I will however leave this question open in case someone else has similar issues. – thepearson Mar 24 '11 at 23:46

This guy wrote a nice howto about it:

share|improve this answer
Does following the steps in that howto actually address the issue raised in the question? – Caleb Apr 20 '11 at 11:03

I have never played with DRBD, but according to:

it seemed that u may need to recreate the DRBD meta database? (which store the sizing info?)

Correct? Just a guess....

share|improve this answer
I am pretty sure that, drbd-meta is only usefull if the device is detached. While online, and once the backing device is resized using drbdadm resize drbd-device, should resize correctly. – thepearson Mar 31 '11 at 7:15

You do not need to fiddle with secondary/primary roles. Just do: 1. LVM resize on both sides 2. On the primary side: drbdadm resize RESOURCE (this will also update the meta-device)

Looking at /proc/drbd should show you a resync of the new portion in progress. If this is not the case try "drbdadm adjust RESOURCE" on both sides.

Now resize the unmounted file-system using the primary side /dev/drbd/by-res/RESOURCE

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.