One may help me with this, because its confusing me:

I have a 1.8T Disk (it's a VM virtual disk), here a snippet of df:

df -TH
Filesystem                          Type      Size  Used Avail Use% Mounted on
/dev/sdb                            ext4      1.8T  1.6T   91G  95% /af

Here the partition info:

parted /dev/sdb print
Model: VMware Virtual disk (scsi)
Disk /dev/sdb: 1924GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:

Number  Start  End     Size    File system  Flags
 1      0.00B  1924GB  1924GB  ext4

So I assume filesystem was setup w/o creating partition first. Now an expand is necessary and this will exceed the 2TB limit. I am just unsure whether this will work w/o trouble? For my undestanding it should be ok to increase the size of the virtual disk and the expand should be done with simply expand the filesystem: resize2fs -f /dev/sdb, so am I correct with this?

3 Answers 3


That would work; ext4 doesn't care about whether the block device it resides on is a partition, a whole hard drive, an LVM volume, a network block device, an iSCSI target… All it sees that there blocks.

  • 5
    Is it worth mentioning that a partition type of "loop" actually means there isn't a partition table at all, and it's just that parted discovered a plausible filesystem at the front of the disk Feb 16 at 15:07
  • Thanks for the quick answers. As this kind of question never crossed my way, your answer proofed what I already had assumed so far.
    – MMAX
    Feb 16 at 15:41
  • 1
    I would add to this that the filesystem usually can’t care on Linux, as long as it’s on something that looks like a block device, it will work, and this is true for pretty much any filesystem on Linux (and most UNIX-like systems) except for specialized stuff like UBIFS that needs a particular underlying block layer to work correctly. Feb 17 at 13:21
  • For future readers: All worked well by expanding the VM-Disk, rescan the disk, umount the filesystem, e2fsck and then resizefs the filesystem.
    – MMAX
    Feb 25 at 10:21
  • @MMAX the unmounting was superfluous; you can enlarge ext4 file systems while being mounted. If that wasn't the case, the right time to unmount would have been before you expanded the disk. Feb 25 at 14:01

This is technically a sort of "f*cked up configuration" from an elegance standpoint, but shouldn't be a problem. It should be fine to simply resize the .vdi or .vmdk and treat it just like you would a normal resize only you can skip the expanding the partition step obviously.

Since it's a VM I would definitely make a snapshot first (if your VM software allows that across a resize) or just copy the file. I assume since you have a 2T VM the space won't be an issue for just an hour or two. Just because it's very cheap insurance to then have absolutely no concern that anything could go wrong, you'll be free to try whatever with no risk or roll back and try something else.

Absent being a little "weird", there is nothing wrong with this from a technical "will it work" configuration. A block device is a block device. I've made the same mistake once or twice on various quick installs of things and it looks a little dumb but is fine. I used to work for a company that did this on purpose out of some sort of (mostly myth) that it might be faster. (the one exception being as long as nothing silly happens to it like corrupting the start of the file system trying to use partition tools on the disk etc).

You can save the first couple megabytes off somewhere to a file on another FS with dd just in case, if that concerns you in your application. The file won't stay in sync as the FS is updated so it's obviously not a perfect backup but is an easy precaution and would give a decent chance of being able to recover from e.g. boot sector corruption and other simple things enough to mount. Although I don't think that will be much of a problem in practice now that you know about this configuration quirk.


Short answer is maybe.

I've not specifically tested this with ext4 and don't know what your hypervisor is / what format the virtual disk is, but this certainly works with XFS on EBS. You would be well advised to test this on a throwaway VM first and make sure you have good backups before attempting on your target if it has any value.

You need to resize the storage first. If you are using a "raw" image in qemu, then it is possible but difficult to do - you need to append a load of null bytes using dd. The syntax of this is rather cryptic - be careful & do read up thoroughly. If you are using qcow2 images it's a lot simpler - just qemu-img resize yourdiskfile 2500G. But there are lots of other possibilities for different storage substrates/hypervisors.

You don't have a partition table so you don't need to worry about the 2Tb limit from MBR.

When I'm building new VMs I always use partition tables (at least from the OS volume) and keep data on a separate volume from the OS.

  • It's on VMWare (see output of parted in question), and yes since it is a production system I definetly will take a backup first and I ususally follow the same approach as you mentioned: disk - partition - filesystem but system was deployed from somebody else which I can't ask anymore.
    – MMAX
    Feb 16 at 15:47

You must log in to answer this question.

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