I recently expanded my RAID 5 Storage Virtual Drive from 6TB to 9TB. The Dell OMSA and the bios for the RAID controller both show I'm at 8382GB. Which is fine.

But when get into Debian and poke around it's still only seeing the 6TB.

When I do an fdisk -l I get this:

Disk /dev/sda: 9000.1 GB, 9000103968768 bytes
255 heads, 63 sectors/track, 1094200 cylinders, total 17578328064 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1  4294967295  2147483647+  ee  GPT

So it now sees that it's 9TB. But the sda1 partition does not. How do I expand this to reflect the size change.... WITHOUT LOSING ANY DATA!


2 Answers 2


As @duskwuff already mentioned, this is a GPT partition table, so fdisk only shows protective MBR content. Use gdisk -l /dev/sda instead. You may be having more than one partition, in which case you will only be able to resize the last one.

The workaround (not recommended) may be software RAID0 (called mdraid in Linux) spanning the partition you want to expand and one created in the new space, visible as one big space to the OS. To avoid data loss you have to use a variant of mdraid without metadata (mdadm --build ..., not mdadm --create ...), check man mdadm. This will however degrade performance, pose another difficulties if applied to root filesystem partition, and has the potential to wipe your data on any mistake.

Possibly there's another, non-destructive solution - if you have a single partition on the disk and you find your filesystem's offset, you can delete the partition and mount the whole disk partitionless, providing offset= value on mount. Not sure if it works with a proper block device (only used with a loop and image files). If it works with partitions still in place then it will work without them too, so you can experiment with mount & offset before touching partition layout. The downside is that such a layout may confuse data recovery software if you need it some day.

To avoid this kind of problems, I always try to use different volume groups for boot/rootfs - partitioned disk, and for data - partitionless disk (expanding it online is a piece of cake, just resizing of the filesystem - resize2fs /dev/sda, assuming it's an EXT{2..4}). This is THE solution for the future.

  • This is not the boot partition. I have another set of drives set to RAID 1 for the boot/os. /dev/sdb. The drive I discuss above is purely for storage. Is there anything I can do/change now so when I need to expand this raid again in the future I don't need to go through this. Now is the time to change since I have time and still have all the data backed up I /could/ restore from.
    – Matt Winer
    Commented Feb 17, 2015 at 2:08
  • So if you can, reformat the RAID disk and use it without partitions. It definitely makes resizing easier and safer. mkfs /dev/sda basically. I will also expand my answer to include another, non-destructive solution. Commented Feb 17, 2015 at 6:14
  • 1
    ok, just to sum up... if I have the ability to restore the data. The easiest and best move for the future would be to run mkfs /dev/sda which will reformat the entire virtual drive. Now I should see all 9TB, restore the data. Then the next time I add a new drive to expand the RAID I can just run resize2fs /dev/sda and it will expand the useable space. correct?
    – Matt Winer
    Commented Feb 17, 2015 at 14:12
  • @Matt Winer - perfectly correct. Unmount /dev/sda* first, and after mkfs run hdparm -z /dev/sda. This is the way I would go. I use partitionless disks with both virtual and physical machines, whenever possible and never ran into a problem with storage resizing. Commented Feb 17, 2015 at 15:07
  • So far so good. Going through the arduous task of restoring 4TB.
    – Matt Winer
    Commented Feb 18, 2015 at 16:12

There is no easy way to do so, if you're not using LVM.

Here is a procedure you can follow safely, if you are very very careful. The best way to be careful would be to backup your data before, obviously.

Fortunately, your partition starts at first sector, so you don't need to worry on this one. Your problem is on the end, which is not your (new) last sector. So you need to update it. So you need to destroy your partition, and create a new one (without formating it!).

fdisk -u /dev/sda

Then, in fdisk utility:

  • d to delete the partition 1
  • p to make sure you have no partition left
  • n to create a new partition:
    • p to make it a primary partition
    • 1 to make it the first partition
    • 1 to make it start on sector 1 (as it was)
    • make the last sector your 'End' of your partition (should be the default answer)

Optionnal (to make your partition bootable):

  • a to toogle the flag, and the 1 to specify the partition

Now you have to write your changes:

  • w

You can now quit fdisk, and reboot your server. Once done, extend your partition at the filesystem level (resize2fs /dev/sda1)

  • I'll put on my big boy pants and try this out. Sounds scary. This has been a lot of work to add 1 drive. Moving forward how do I make this easier for myself? LVM? Something other than Debian?
    – Matt Winer
    Commented Feb 16, 2015 at 18:15
  • 1
    LVM is probably the best option: well documented, easy to use, and last but not least: safe! Commented Feb 16, 2015 at 20:57
  • 1
    Er… you DON'T want to use fdisk here. The disk is too large to use MBR; it's actually GPT formatted. Use parted instead.
    – user15323
    Commented Feb 16, 2015 at 21:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .