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

sysadmin1138
  • 996
  • Oracle VM does this, too - for "local storage". – Nils May 22 '12 at 20:49
  • 3
    I missed this question and started a new one which covers the same ground: http://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
  • 1
    ... and another one at http://unix.stackexchange.com/questions/206141/partition-table-less-hdd – derobert May 29 '15 at 18:05
  • Works but leads to issues that will end up wasting time as shown here - https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/6.1_technical_notes/ar01s04. – slm Sep 15 '18 at 00:30

7 Answers7

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.

Gilles 'SO- stop being evil'
  • 829,060
  • 2
    Confusion, ahoy! My internal meter is currently leaning towards "misguided attempt at optimization". – sysadmin1138 May 29 '11 at 23:35
  • 7
    another con: makes it harder to later split the partition into two. – Kim May 30 '11 at 03: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 04 '13 at 02: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 04:35
  • @Kim - why would you want to subdivide a partition later? – warren Jan 26 '16 at 15:02
  • 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 02 '18 at 10:15
  • In a commercial environment, a SAN storage might be involved - and depending on how good a configuration user interface is provided by the storage vendor, it can be very easy to accidentally present a wrong SAN-based "disk" (known as a "logical unit" or LUN) to a wrong computer. The user interface must not completely block presenting the same LUN to multiple SAN adapters, because failover clustering and redundant SAN connections are fairly common things in such environments. – telcoM Oct 21 '20 at 07:37
  • Why is extending the filesystem not easier? If the disk is partitioned, I'll have to extend the partition first before I can extend the filesystem. That's two commands instead of one. (growpart /dev/sda 1 && btrfs fs resize max /mnt) – fnkr Dec 22 '20 at 17:13
  • Extending the filesystem? Who would install a filesystem directly to an unpartitioned disk, instead of to a partition of it, and not from the beginning use the complete disk for it? The only usefull way to do this, is when also installing a second filesystem to that same unpartitioned disk, but with an offset. Which is in fact a primitive partitioning of the disk. – db-inf Jul 11 '22 at 10:42
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!).

Nick Gasparovich
  • 251
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.

jlliagre
  • 61,204
  • 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
  • @jllagre which is why the filesystems don't know or care about the disk cache; that is managed by the kernel which normally turns it on, at least on Linux; maybe Solaris isn't so smart? – psusi May 31 '11 at 15:17
  • It is not a question of being smart or not, just different priorities (performance vs reliability/data integrity). – jlliagre May 31 '11 at 16:23
  • @jlliagre no, you get both reliability and performance when you do it right. – psusi Jun 01 '11 at 13:42
  • 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 01 '11 at 16:22
  • @jlliagre, that is why filesystems and applications that care use fsync() or similar to flush the kernel cache, which also flushes the disk cache if it is enabled. – psusi Jan 20 '14 at 04:38
  • 1
    @psusi Whether fsync will flush the disk cache or not looks to be file system dependent. – jlliagre Jan 20 '14 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.

maxschlepzig
  • 57,532
  • 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 '22 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 '22 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 '23 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.

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

codechimp
  • 207
  • 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 '20 at 07: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.

Roux
  • 101