Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. 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 ran into something a couple of weeks ago that I'd never seen before: A filesystem (ext3 I believe) installed to a storage device without a partition. In essence /dev/sdb was the entire filesystem. I know many filesystems can be extended into empty space, so doing this allows extending without dealing with LVM or some other kind of volume manager, but are there any other advantages for setting up storage this way?

The specific case I saw was as the ephemeral data volume for a number crunching server, the boot and root volumes were traditional partitions on a different storage device entirely. -

share|improve this question
Oracle VM does this, too - for "local storage". – Nils May 22 '12 at 20:49
I missed this question and started a new one which covers the same ground: unix.stackexchange.com/q/52389/4801. That question has now been closed, but some of the answers there may also be useful to readers of this Q, and might be merged in here. – dubiousjim Oct 21 '12 at 22:13
... and another one at unix.stackexchange.com/questions/206141/… – derobert May 29 '15 at 18:05
up vote 15 down vote accepted

Pro: you don't waste one disk sector on a partition table. (Yay.)

Pro: the disk can be used in an operating system that doesn't support PC-style partitions. (Like you're going to use one.)

Con: this is unusual and may confuse co-sysadmins. (See?)

Irrelevant: extending the filesystem is not easier if it's directly on the disk than if it's in a partition, nor vice versa. (Being on LVM would make it easier.)

Conclusion: it works, but it's not a good idea.

share|improve this answer
Confusion, ahoy! My internal meter is currently leaning towards "misguided attempt at optimization". – sysadmin1138 May 29 '11 at 23:35
another con: makes it harder to later split the partition into two. – Kim May 30 '11 at 3:40
Came across this superuser Q&A which has some good examples using hexdump and od which show in very concrete terms what's going on with a /dev/sda vs.. /dev/sda1 setup. – slm May 4 '13 at 2:10
It is a bit simpler to extend the volume on a whole disk since you don't first have to extend the partition. – psusi Jan 20 '14 at 4:35
@Kim - why would you want to subdivide a partition later? – warren Jan 26 at 15:02

Not sure about how this would apply to Linux but with native ZFS, one reason it is recommended to create pools on whole disks and not partitions is in the former case the disk write cache can be enabled.

Several other reasons also mentioned here:


Conclusion: it works, and might be a good idea depending on the filesystem.

share|improve this answer
Good to know. In this specific case it was in the cloud! so storage is pretty heavily abstracted by the time it comes to system setup. – sysadmin1138 May 30 '11 at 11:25
What on earth does the disk write cache have to do with whether or not a partition table is in use? – psusi May 30 '11 at 15:06
The write cache cannot be enabled at a partition level. When enabled, it affects the disk as a whole. If a file system is using a whole disk, it "owns" that disk so it can turn that cache on and off without any collateral risk. Otherwise, doing it might affect another disk consumer needing that cache to be disabled for its own reasons. – jlliagre May 30 '11 at 21:37
Sure, but having the OS blindingly turning on the cache without knowing the file system or raw device consumer requirements is not a reliable approach. There are applications like databases that need to be sure a committed transaction is on disk and not just in memory. – jlliagre Jun 1 '11 at 16:22
@psusi Whether fsync will flush the disk cache or not looks to be file system dependent. – jlliagre Jan 20 '14 at 12:37

Placing a filesystem on a disk device without creating any partition is not that uncommon.


  • when you want to use the whole space anyway, then you don't have to waste your time with some partitioning tool
  • you don't have to worry about incompatibilities of the 'standard' partition format (btw, what partition format is the standard, the DOS one, the BSD one?), e.g. the DOS partition format only allows partitions up to 2 TB when using 512 byte logical sectors!
  • you don't have to worry about partition induced alignment issues on drives with (currently) unusual sector sizes (e.g. 4 k) - sure, current distributions should ship partitioning tools that do correct alignment with different sector sizes

Being able to resize a filesystem on a raw device is not a good reason. The space you save that way, you can't use for other things. Thus, you can just directly create the filesystem on the whole device.

share|improve this answer

I see the real benefit when this is done in a virtual environment. Since our VMDK's are stored on our NAS, we can grow them dynamically.

If we're using partitions, either we need to use LVM (and the overhead associated with it) and chain the partitions together, or we need to take down the host (or filesystem if not in use) to use something like gparted.

However, if you use the whole disk instead of a partition, you can force a rescan on your SCSI disks and use resize2fs to grow the filesystem while it's online (and in use!).

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.