Wandering Thoughts archives

On how PCs boot and hard disk partitioning

Starting from the very early days, PCs have booted in a very simple manner: the PC BIOS found the boot disk, loaded the first 512 byte sector from it into memory, verified that it had a valid MBR signature, and then jumped to the start of the sector (which had better be code). That was it. The code in the boot sector was responsible for doing everything else, calling on BIOS services as necessary for things like reading more data from the disk.

(Generally the code in the first sector is just smart enough to load the rest of the bootloader's code from disk. It's the second stage code, or sometimes even third stage code, that is capable enough to do all sorts of traditional bootloader things like displaying menus and so on.)

This simplicity means that in theory, a PC BIOS is completely agnostic about the presence and contents of the traditional MBR partition table (which under normal circumstances is located at the end of the first sector, reducing the amount of space available for MBR boot code somewhat). The MBR partition table and extended partitions only matter to the boot code, the OS, and any tools that you use, so you could replace them with another partitioning scheme entirely if you wanted to and everything agreed on it. I believe that this was (and is) sometimes done by various Unixes.

(In practice there are undoubtedly PC BIOSes that do care about the MBR partition table and get upset if it isn't there or isn't right. Also, a non-MBR partitioning scheme will make any MBR-based tool think that your disk is unpartitioned, so most OSes with their own partitioning schemes embed them inside one or more MBR partitions.)

Since MBR partitioning is a convention, you can replace it with another one without affecting how PCs boot (especially if you leave behind a more or less fake MBR to pacify MBR-aware things). You don't even need the BIOS's cooperation, you can do it entirely on your own.

(Note that some BIOSes, especially laptop BIOSes, have features that know about hidden MBR partitions and so on that are used for stuff like special recovery modes. I believe that this is generally separate from actually caring about them for ordinary booting.)

Sidebar: Linux and partitioning

Linux is unusual as a PC Unix in that it does not have its own partitioning scheme but uses normal PC primary and extended partitions. I believe that the reason for this is essentially historical. All of the other PC Unixes descend from ancestral Unix versions that already had their own disk partitioning schemes when they were ported to PCs. The simple way to do these ports was to embed the existing partitioning scheme inside a PC partition and then add a little bit of extra code to find it, rather than rewrite the entire disk partition handling code to take information from either the PC partitions or the Unix's own disk partition scheme.

(These Unixes generally did not want to throw away their existing partitioning schemes, partly because they wanted to be portable to non-PC systems and partly because they had a lot of existing tools, documentation, and practice that worked with the current partitioning schemes. Some of the resulting workarounds are a bit awkward.)

By contrast Linux started from scratch with no existing disk partitioning scheme to carry over into the PC world. So it made perfect sense to use the existing PC partition stuff (which Linux needed to understand a bit of anyways) rather than invent an entire new layer of disk partitioning.

About SATA port multipliers

I mentioned SATA port multipliers in passing yesterday but then I just assumed that everyone knew what they are (as I have done before). So, time for the explanations.

Put simply, SATA port multipliers let you talk to several disks over a single SATA port and cable. If you're old enough, you may now be asking why we'd want to get rid of one of SATA's advantages and go back to the bad old days of things like SCSI and multi-device IDE. The short answer is density; using port multipliers lets you talk to a lot more SATA disks than you could otherwise. Our iSCSI backends are a perfect illustration; with port multiplication it only takes us one PCIe card and three or four cables (depending on the disk enclosure) to talk to twelve SATA disks, and we could talk to more disks with a bigger disk enclosure. Without PMP, we could not even fit enough SATA connectors into the available physical space for PCIe card edges.

(SATA port multiplication is generally abbreviated PMP, and I'm going to do so for the rest of this entry.)

Unlike SCSI or IDE, port multipliers require hardware support on both sides; you don't directly connect to multiple SATA drives. The computer needs to have a multiplier-capable chipset (with a driver that knows how to use it) and the disk enclosure needs its own de-multiplier daughter cards that splits the connections apart to individual disks. PMP is generally backwards compatible with plain SATA and on the computer side a PMP-capable chipset is perfectly happy to talk to individual disk drives. What happens with PMP disk enclosures is that if you talk to their SATA ports without doing PMP, you only see the first drive behind each PMP SATA port; all of the other drives on the port are invisible. This can happen either if you have a non-PMP chipset or your chipset is PMP-capable but you don't have driver support for it yet.

(In Linux, this first drive is the drive that is enumerated as drive 0.)

In theory PMP allows up to fifteen drives to be behind each port. I believe that actual SATA chips have lower limits, and this may vary between chipsets; I have read discussions that suggest that common PMP-enabled chipsets have limits of 5:1 or 4:1 multiplication (that is, only four or five drives visible per SATA port).

There is one potentially important consequence of having multiple disks on a single SATA port. If something happens on the port and the SATA link must be reset (drivers like doing this for error recovery), you will lose contact with all disks on the port for the duration of the reset. So far this has not caused us problems. Note that hotswapping disks seems to lead to a port reset in our current environment.

Quality of implementation issues for PMP disk enclosures vary significantly in at least two ways: how drives are split between ports and how SATA drive numbers map to physical drive slots. We have two different brands of 12-disk enclosures with our iSCSI backends. The first brand has four ports with 5, 5, 1, and 1 drives each respectively (so yes, the last two ports are not even PMP, which I suppose saved the maker a PMP de-multiplier card) and the 5-drive ports map to physical slots in the order '2 3 4 5 1'. The second brand has three ports with 4 drives each and the physical slots are mapped sequentially, which is what you want for sysadmin sanity.

(Fortunately we have far more of the second brand that the first brand and the disks in the first brand's enclosures have been very reliable. Both models are now out of production so there's no point in naming names.)

PS: do not expect these things to be documented for inexpensive disk enclosures (and they're basically all inexpensive). I recommend careful experimentation and mapping in the OS of your choice.

Mouse scroll wheels versus buttons that you actually want to use

I've written before that I don't want a mouse where the middle button is a scroll wheel. At the time I was brief about why, but today I'm going to expand on that and explain why you can't combine the two functions in something where both work as well as they would independently. In short: if you have a scroll wheel that is also a mouse button, using one or the other necessarily has to kind of suck.

The core problem is one of activation pressure. A good mouse button takes relatively little finger pressure to activate. You don't want too little finger pressure because then it gets activated accidentally, but the more pressure it takes the more fatiguing it is to use the button (and to some extent the slower and more awkward to do so). However, a low activation pressure for the button function of a scroll wheel is in strong conflict with using the scroll wheel as a scroll wheel.

To use a scroll wheel comfortably, you need to be able to rest your finger on the wheel without having anything happen. This means that scrolling itself needs to require some pressure to do, especially if you want to scroll in perceptible discreet steps (perceptible steps imply that there is extra resistance between steps, so that it easy to stop after a step). This pressure is not exerted directly downwards but it does involve a certain amount of downforce, especially if the user is a bit sloppy or hurried. To make using the scroll wheel work well, you need this downforce from using the scroll wheel to not activate the button function; otherwise, using the scroll wheel to scroll would come with bonus random button clicks, which is sure to irritate you.

Ergo you have a conflict. You can either have a nice to use button with a hair trigger, hard to use scroll wheel, or you can have a scroll wheel that works well with a button function that takes significant extra force to use. For relatively obvious reasons, every 'scroll wheel middle button' mouse I've seen takes the second approach.

(If you have a scroll wheel mouse, you can try this yourself; feel out the amount of force that's required to activate each button. With every scroll wheel mouse I've ever used, the left and right buttons have relatively light force while the middle scroll wheel requires perceptibly more.)

I kind of like the scroll wheel, but I use the middle mouse button all the time, almost literally. This makes the common scroll wheel tradeoff a very bad thing for me; it is exactly reversed from my usage pattern.

(There are also issues with finger positioning, where the scroll wheel is too far back for the tip of my finger to naturally rest on top of it. This might just be me and it might go away if I used scroll wheels more, which may come to pass.)