64-bit Architecture

64-bit's "big gun" is memory support. Although the Pentium's 4GB memory limit was impressive several years ago, 4GB doesn't go very far with today's high-end server applications. Itanium processors' memory support depends on their accompanying support chipset: Original Itanium computers supported 16GB of RAM per processor, whereas newer Itanium 2 computers support up to 64GB of RAM per processor?with up to 256 processors. That's a lot of RAM and should be enough for quite a few years. Itanium 2 processors also have three levels of cache memory, running at extremely high speeds. These caches help reduce the processor's need to access main memory by storing frequently used information within the caches. Sun Microsystems offers an interesting analogy that puts 64-bit memory capabilities into perspective: A 32-bit computer has enough addressing space to store the name and address of every person who has lived in the United States since 1997. A 64-bit computer can address enough memory to store the name and address of everyone who has ever lived on Earth.

Itanium 2 computers will also include support for Infiniband, the replacement for the PCI peripheral bus architecture you're already familiar with. PCI, as you know, supports the use of busmastering devices that can directly access main memory, removing some processing burden from the computer's main processor. Infiniband, however, uses a completely switched architecture, giving every device direct access to main memory and the processors. This architecture is analogous to a switched network environment, in which every network device has dedicated bandwidth, rather than having to share that bandwidth with other devices. Infiniband is faster, too, with bandwidths of up to 6Gbps. That's hundreds of times faster than even the fastest PCI bus.

Partition Management

Itanium machines use a radically new change to disk partitioning. Your 32-bit servers rely on a master boot record (MBR), which identifies the partitions on a disk by their cylinders, sectors, and head locations. The MBR also includes the partition's type, which can include primary, non-DOS, extended, and so forth. The MBR tracks which partition is active (bootable), as well. Unfortunately, the MBR scheme was designed decades ago when nobody could imagine hard disks so large that more than four partitions would be needed, so the MBR supports a maximum of four partitions. Itanium machines are built for the future, though, and use a much more flexible scheme called the GUID Partition Table (GPT).

Each GPT-based disk assigns two globally unique identifiers (GUIDs) to each partition on the disk. One GUID identifies the partition, whereas the other represents a partition type. Partition types include

  • EFI System Partition (ESP)? This partition holds the operating system-specific boot loaders for the operating systems on your server. I'll discuss these in more detail in the next section, "Boot Architecture." Each server has only one ESP, which is at least 100MB in size and no larger than 1GB. The ESP is usually sized at 1% of the disk's total size. The ESP doesn't show up in Windows at all and is accessible only from the server's EFI command processor.

  • Microsoft Reserved partitions (MSRs)? This special type of partition stores information for dynamic disks. I explain MSRs in more detail in the sidebar titled "Understanding MSRs."

  • Microsoft Data partitions? These are regular partitions created in Explorer or the Disk Manager console, and they can be accessed by other operating systems installed on your server, unless of course you protect them by using NTFS permissions.

  • OEM partitions? These are created by some server vendors and include special diagnostic utilities, setup utilities, and so forth. Vendors' utilities access the partition by its GUID because these partitions don't appear in Explorer. You can access them in the Disk Management console.

Itanium machines' partition management is extensible and much more flexible than the partition management system on 32-bit machines (which dates back to IBM's original PC computer from 1980).

Understanding MSRs

Understanding these is easier if you think about how 32-bit Windows treats disks. Remember that a standard MBR-based disk is treated by Windows as a basic disk. However, you can convert basic disks to dynamic disks. When you do, the partition information is transferred from the MBR to a Logical Disk Manager (LDM) database. Each dynamic disk stores an identical copy of the LDM database, which is located on a hidden partition located on the last cylinder of the disk (or the last 1MB, whichever is smaller).

64-bit Windows calls a GPT-based disk a basic disk and lets the server's firmware manage the partitions using the GPT. Converting a basic disk to dynamic moves the GPT information into the LDM database?essentially the same as in a 32-bit server, so far. However, GPT doesn't support the fancy partitioning Windows uses to hide the LDM database on a 32-bit machine. Instead, 64-bit Windows creates an MSR partition to store the database. Windows actually creates the MSR even if the disk is left as a basic disk, so the MSR is there if the disk is ever converted to dynamic.

MSRs are sized based on the physical disk size. The MSR is 32MB on a disk of up to 16GB and is 128MB on larger disks. MSRs are formatted as FAT16, which can be natively read by Itanium machines' EFI command processors. MSR partitions can't be seen in Explorer, but you can see them in the Windows Disk Management console.

Boot Architecture

One of the most noticeable changes in the Itanium architecture is its completely new boot architecture, which bears a closer resemblance to RISC-based computers (such as the Alpha) than to the traditional PC boot process, which is more than 20 years old. To quickly review, PCs use their BIOS settings to determine from which device?CD-ROM, floppy, hard disk, or network?to boot. The BIOS then looks for a boot sector on the appropriate device and loads it into memory. The boot sector contains code that looks for an operating system loader, such as Windows 2000's Ntldr. The operating system loader is responsible for getting the operating system up and running. In Windows's case, that includes running Ntdetect.com to find out what basic hardware is present, loading a SCSI driver (Ntbootdd.sys) if necessary, and so forth. Special provisions abound, including the El Torito bootable CD-ROM specification, which is supported by most servers. All this complexity makes it very difficult to create machines that can boot to different operating systems, troubleshoot missing or corrupted boot sectors, and so on.

Itanium machines work completely differently: They store boot information in a special nonvolatile memory called firmware. Intel has developed an interface called Extensible Firmware Interface (EFI), which controls the settings in the firmware. Itanium machines also store their boot sector code right in the firmware, and not on disk. As a result, Itanium machines don't need Ntldr or a Boot.ini file. Itanium machines also use a secondary boot loader stored on disk, named Ia64ldr.efi. Note the .efi file extension, which indicates a file that can be executed by the EFI firmware. The EFI itself contains a command processor that is accessible from a boot menu and lists all the partitions available to it. You can execute the command processor's Map command to redisplay the list if necessary. The list includes

  • A GUID for each partition? This is a long ID number, such as FD47389-87D4-116B-9488 849B7298A657.

  • A sequence number? Indicates the partition's location on the disk. These are listed as blk0, blk1, and so forth.

  • An alias? If a partition is formatted with a file system that EFI can read (which currently includes FAT, FAT32, and Joliet CD-ROMs), the partition is assigned an alias, such as fs0 or fs1.

Within the command processor, you can type a block name followed by a colon to access a particular partition. For example, entering blk1: and pressing Enter takes you to the second partition (the first partition is blk0). If the partition's file system is readable by EFI, you can use a standard Dir command to display a directory listing. For partitions with an alias, such as fs0:, you can also enter the alias name to access the partition: Type fs0: and press Enter.

Another important change is that EFI doesn't support El Torito bootable CD-ROMs, so you can't just pop a Windows Server 2003 CD in the drive and restart the computer to launch Setup. However, EFI does natively recognize the Joliet CD-ROM file system, so you can access the contents of the CD-ROM from within the command processor and launch Setup that way.

For example, if your Windows Server 2003 CD-ROM is assigned the partition alias fs2:, you can load the command processor, type fs2:, press Enter, and simply execute the Setup bootloader (Setupldr.efi). All 64-bit-compatible operating systems include an EFI-compatible Setup loader, which you can execute from the command processor.

The firmware's boot menu is essentially a macro system, allowing a single menu option to switch to a specified partition and execute a particular EFI secondary boot loader. This architecture enables you to easily set up multiboot computers without having to remember complex ARC naming paths (such as Boot.ini uses), troubleshoot the multifile 32-bit Windows boot system (Ntldr, boot.ini, Ntdetect.com, and so forth), or deal with master boot sectors and other disk-based boot schemes.

The new boot architecture takes some getting used to, though. You can think of it as a kind of mini-Recovery Console and boot menu, built right into the server hardware itself. After you're accustomed to using the new architecture, you'll find that it's more flexible and powerful than the decades-old system 32-bit servers use.