37

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. -

24

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?)

Con: if you install another operating system, it might think that the disk contains garbage and make it easy to accidentally overwrite it by selecting the wrong disk — whereas operating systems generally leave alone partitions whose type they don't understand.

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.

  • 2
    Confusion, ahoy! My internal meter is currently leaning towards "misguided attempt at optimization". – sysadmin1138 May 29 '11 at 23:35
  • 6
    another con: makes it harder to later split the partition into two. – Kim May 30 '11 at 3:40
  • 3
    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
  • 4
    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
  • 2
    In a non-commercial environment, installing another OS may be relevant - but who multiboots in a commercial env? I am disturbed that this is the canonical answer. Nothing wrong with it, except that it's opinion. I'm on the fence about partitionless disk use, but some good reasons are given below. – Graham Nicholls Aug 2 '18 at 10:15
19

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:

http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#Storage_Pools

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

  • 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
  • 1
    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
  • 3
    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
  • 4
    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
  • 1
    @psusi Whether fsync will flush the disk cache or not looks to be file system dependent. – jlliagre Jan 20 '14 at 12:37
11

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

Advantages:

  • 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.

16

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!).

  • Good point! With virtual disks (as you can create, remove and resize them as needed) partitions seem to be an useless layer. – pabouk May 12 '17 at 8:14
2

An answer that hasn't been listed is, if you don't create a partition you don't have to wait for the Kernel to detect it which might only be after a reboot.

One use case could be a EC2 EBS volume that you add to the node and want to initialise on first boot.

If your initialisation process creates a partition you run the risk of having to reboot for the Kernel to see the newly created partition. You'd typically see a message like:

Error: Error informing the kernel about modifications to partition /dev/xvde1 -- Device or resource busy. This means Linux won't know about any changes you made to /dev/xvde1 until you reboot -- so you shouldn't mount it or use it in any way before rebooting.

In this case your initialisation process would have to perform a reboot and then continue to add a filesystem to the newly created partition.

If you know you're only going to need a single partition you might as well skip it thereby not running the risk of requiring a reboot.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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