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

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.
–
dubiousjimOct 21 '12 at 22:13

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.

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.
–
sysadmin1138May 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?
–
psusiMay 30 '11 at 15:06

1

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.
–
jlliagreMay 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?
–
psusiMay 31 '11 at 15:17

2

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.
–
jlliagreJun 1 '11 at 16:22

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.

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