When and why do block devices need to be partitioned?

Question

Possible Duplicate:
The merits of a partitionless filesystem

So I've got a block device, say /dev/sda or /dev/loop0. Clearly if I want to boot from the former, or I want to subdivide it into segments with separate filesystems, I need to partition it. But suppose I don't have those needs. Instead, I just plan to use my entire block device as storage. Maybe I'll make it part of a raid volume, or maybe I'll encrypt it with cryptsetup, or maybe I'll make it a PV for LVM. Or maybe I just want to install a filesystem on it directly. In at least some of these cases, there doesn't seem to be any technical obstacle to using the device unpartitioned. That's what we generally do with block devices generated by losetup, and one can do it too with regular hard disks. I know because I've done it.

Now, there are dangers to this. For instance, if you ever go on to run fdisk /dev/sda, you won't see anything sensible. And you might accidentally write a partition table or something like that to your device, and then the data you had on the unpartitioned device would be hosed. Maybe if you even boot into Windows with the device attached, it will get hosed. People tell scary stories.

But I'd just like to understand, if the device is only ever connected to your Unix setup (and to keep things simple, let's stick to Linux only), and you never try to write a partition table or MBR to it or anything like that, are there any other downsides to using a storage device unpartitioned? I'm not proposing to do it; I just want to understand what the genuine reasons for not doing it are.

On the flip side, is there any obstacle or downside to partitioning the block device /dev/loop0? Perhaps there'd be no advantage to doing so. But I expect it would work, wouldn't it? Here, too, I'm only asking because I want to understand the reasons behind our standard practices.

Solution 1

The kernel, and other programs, occasionally look for partitions on the disk, for example at bootup. If you have a partition table: that's great, it will find them, and you can put anything you'd like inside that partition.

But if you don't have partitions, then you have to be careful not to put something inside the disk that might look like a partition! Otherwise, on a subsequent boot, that data might get inadvertently interpreted as a partition table.

I'd always make a partition table, just to be safe.

Solution 2

The partitioning is not required in general. For the boot device it is required only to a) allow the boot partition to be accessible via the BIOS API (to allow the MBR boot loader to load the grub or other boot loader properly if the latter is installed onto partition) and b) allow the boot partition to be readable by the grub or other boot loader (for example, lilo can't read LVM's)

From all other points of view there is no need to have a device to be partitioned unless you have some reasons for it.

Solution 3

A partition is just a logical subdivision of a block device (or let's use mass storage space).

You don't have to subdivide it at all, except for things like limitations, etc. However, if you plan on putting a filesystem on there, it's another story.

You can format without partitioning, just creating the filesystem structure, and that's it. Now, if you want to have this partition to be accessible from things like BIOS or other low level stuff, it's a good idea to use partition tables and MBRs, with their copies at certain points (partitioning and formating tools do that for you).

And that's basically the only reason for actually partitioning, other than logical subdivisions for the user (i.e. you), for whatever reason.

This goes probably beyond your question, but the advantage of having a system partition and a user partition, is that you can format one, without losing the other. You'll probably format the system way more often than the user directories. You don't need to save all user data on external drives, or whatever. Also, you can use that partition to backup some system settings.

Comments

[Richard Fortune]

Question was closed: thanks for the link to the earlier question, I thought I had reviewed all the /partition questions before asking, but I missed that one.

[Stéphane Chazelas]

grub2 can read LVM, raid (including raid5) and filesystems on whole disks (doesn't have to be on a partition). filesystems reserve space for a boot loader (its primary stage at least). For instance, you can have a bootable partition, so in theory at least, you don't need partitions to boot either.

[Serge]

@sch, it seems I am behind the times... it used to be not able at least. Time is going, things are changing. anyway thanks for the info

[Richard Fortune]

Thanks. I do appreciate the advantages of having / and /home on different filesystems. I was wondering more about some additional storage, that's just going to hold additional data; or that's going to be subdivided using LVM. And suppose we don't need to access it via BIOS, since we're not going to boot from it. In that case, why is it a "another story"? It sounds like you're saying there are reasons to partition the device before you put a filesystem on it. But the reasons you mention are ones I meant to set aside: don't need an MBR. Don't need even one copy of a partition table.

[Richard Fortune]

Also, I'm aware that GPT-style partitioning does make a copy of the partition table. Does MBR-style (or whatever the traditional form of partitioning is called) also do so? I wasn't aware of that.