I received an interesting question from a colleague today, I didn’t have a great answer besides “it’s generally accepted practice” and I’m interested to hear others’ thoughts.
Say you’ve got a second disk (/dev/sdb) in a system that is going to be used purely for a single non bootable ext4 filesystem. Usually, you’d create a GPT partition table, populate it with a single partition that spans the entire remainder of the disk, and then create the ext4 filesystem on that partition (/dev/sdb1). However, you could just go mkfs.ext4 /dev/sdb and get a mountable, working filesystem.
In this scenario does it really matter if we create a partition table or not? The only reason I can think of is that the partition table provides a form of metadata about the filesystem, eg. its type and minimum/maximum extents.
It’s not a big deal if you skip the partition table for a single ext4 filesystem, but it’s usually better to use one for these reasons:
Organization: Helps manage the disk and its metadata.
Compatibility: Some tools expect a partition table.
Future changes: Makes it easier to add more partitions later.
If you’re sure you’ll only use one partition, skipping the table is fine, but it’s good practice to use it.
Edit: looking into it, it is possible to use a drive without a partition table.
Would not use it for boot devices tho…
I suspect I have been spoiled by ZFS automatically creating partitions when passed a whole drive…
You’ll very quickly discover why, when you connect a raw disk to a Windows machine, and it pops-up an “Initialize Disk” dialog with the “OK” button already focused by default. Very quick way to loose a few TB of data when Window focus is stolen, speaking from experience.
Thanks We’re in cloud where it’s pretty unlikely that you’d see these kinds of situations but it we had a good discussion about the cases you’ve all mentioned
I’ll add another one, there are some badly behaved hardware RAID controllers that will, without asking, write configuration data to what they consider “uninitialized” disks either in the area before the bootloader, or at the very end of the disk. If there’s no partition table, that means your filesystem is taking up the whole disk which also means the controller may have just corrupted some filesystem data in that area.
Obviously this is only an issue if you’re using the disks as JBOD but you get the idea…
We’re in cloud where it’s pretty unlikely that you’d see these kinds of situations but it we had a good discussion about the cases you’ve all mentioned