55

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

Improve this question
4

7 Answers 7

Reset to default
35

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.

Improve this answer
9
  • 2
    Confusion, ahoy! My internal meter is currently leaning towards "misguided attempt at optimization".
    – sysadmin1138
    May 29, 2011 at 23:35
  • 7
    another con: makes it harder to later split the partition into two.
    – Kim
    May 30, 2011 at 3:40
  • 6
    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, 2013 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, 2014 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, 2018 at 10:15
25

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

Improve this answer
1
  • Good point! With virtual disks (as you can create, remove and resize them as needed) partitions seem to be an useless layer.
    – pabouk - Ukraine stay strong
    May 12, 2017 at 8:14
24

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.

Improve this answer
9
  • 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, 2011 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, 2011 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, 2011 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, 2011 at 16:22
  • 1
    @psusi Whether fsync will flush the disk cache or not looks to be file system dependent.
    – jlliagre
    Jan 20, 2014 at 12:37
17

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, except for low-level hacking. Thus, you can just directly create the filesystem on the whole device.

Improve this answer
3
  • Oh yes, you can use the leftover space usefully. You can, for instance, install a 2nd filesystem to it, with an offset from the beginning of the disk. A kind of selfmade partitioning, where your recollection of the offset serves as partiton table. This would be a simple attempt to hide the 2nd partition.
    – db-inf
    Jul 11, 2022 at 10:46
  • @db-inf Ok, you are right - technically you can use that space for something. I've updated my answer. :)
    – maxschlepzig
    Jul 11, 2022 at 11:10
  • ... a further big pro is that you can mount/debug/edit such a "file system on raw device" very easily outside the VM or machine it belongs to. Imagine a VM not booting, and you cannot mount its vDisk on the VM-hosting host, just to look what's wrong... We have some VMs set up the "default" way with anaconda (and thus, with LVM). Since we use Ceph/rbd on the hosts, a simple "rbd device map pool/vol", followed by "mount /dev/rbd0 /mnt" would show its contentright away, but now we had to install LVM on the host (which does not need it) and fiddle with pvscan and the like.
    – Christian
    Aug 13 at 20:54
4

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.

Improve this answer
1

I do think routinely but I'm finding it to be a nuisance for USB sticks. AT least in Linux.

If, after mounting a partitionless USB stick, you unmount the "partition", it seems to drop the drive altogether. That is, in order to remount, you have to physically remove and re-insert the USB stick.

Improve this answer
1
  • 2
    If you are using a GUI tool to mount your USB sticks, this might be a feature of the GUI tool, not of the unmounting procedure itself. The udisks service underlying removable media support on major Linux desktop environments tends to equate unmounting a removable media for preparing it for physical disconnection, which has exactly the effect you describe.
    – telcoM
    Oct 21, 2020 at 7:40
0

A small bit that seems to be missing from the discussion:

TL;DR: Partitionless disks (HDD or SSD) do not work with Microsoft systems. At least W10 firmly refuses to recognize a filesystem from a partitionless disk claiming "uninitialized volume".

I have been using partitionless disks for archival purpose for quite a while for a basic reason that at some point when disks overgrew MBR, fdisk from my computer could not make GPT partitions, and I did not bother to learn now to do GPT partitioning with gpt tool. Everything went fine until I had to share one of such disks with a person who uses windows.

https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-and-gpt-faq clearly states that "superfloppy" is allowed only for removable media. HDD in a USB dock is not removable in their opinion. So it is not a bug, it is a feature.

Improve this answer

You must log in to answer this question.

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