Very simple note on disk device "paths" in some common architectures.

਍ഀഀ
਍㰀戀爀㸀ഀഀ ਍㰀䈀㸀䴀愀椀渀 䌀漀渀琀攀渀琀猀㨀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
਍㰀䈀㸀ഀഀ 1. A GENERIC (INCOMPLETE) OS MODEL.
਍㰀䄀 栀爀攀昀㴀∀⌀猀攀挀琀椀漀渀㈀∀㸀 ㈀⸀ 吀䠀䔀 䐀䔀嘀䤀䌀䔀 吀刀䔀䔀 ☀ 䘀䤀刀䴀圀䄀刀䔀 瀀爀攀ⴀ戀漀漀琀 䤀䴀倀䰀䔀䴀䔀一吀䄀吀䤀伀一匀㨀 伀瀀攀渀 昀椀爀洀眀愀爀攀 ☀ 唀䔀䘀䤀⸀㰀⼀䄀㸀㰀戀爀㸀ഀഀ 3. MBR (BIOS), GPT (UEFI).
਍㰀䄀 栀爀攀昀㴀∀⌀猀攀挀琀椀漀渀㐀∀㸀 㐀⸀ 䄀 嘀䔀刀夀 匀䠀伀刀吀 匀䔀䌀吀䤀伀一 伀一 匀伀䴀䔀 匀䌀匀䤀 吀䔀刀䴀匀⸀㰀⼀䄀㸀㰀戀爀㸀ഀഀ 5. WORLD WIDE NAME IDENTIFIERS.
਍㰀䄀 栀爀攀昀㴀∀⌀猀攀挀琀椀漀渀㘀∀㸀 㘀⸀ 䈀䰀伀䌀䬀 䤀伀Ⰰ 䘀䤀䰀䔀 䤀伀Ⰰ 䄀一䐀 倀刀伀吀伀䌀伀䰀匀⸀㰀⼀䄀㸀㰀戀爀㸀ഀഀ 7. JUST A FEW NOTES ON VMWARE.
਍㰀䄀 栀爀攀昀㴀∀⌀猀攀挀琀椀漀渀㠀∀㸀 㠀⸀ 䨀唀匀吀 䄀 䘀䔀圀 一伀吀䔀匀 伀一 一䔀吀䄀倀倀⸀㰀⼀䄀㸀㰀戀爀㸀ഀഀ 9. JUST A FEW NOTES ABOUT STORAGE ON UNIX, LINUX AND WINDOWS.
਍ഀഀ ਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
਍㰀戀爀㸀ഀഀ In this simple note, we try to address some key concepts in "access of storage". For example, what driver models
਍愀爀攀 最攀渀攀爀愀氀氀礀 椀渀 甀猀攀 椀渀 愀 挀漀洀洀漀渀 伀瀀攀爀愀琀椀渀最 匀礀猀琀攀洀㼀 伀爀Ⰰ 眀栀礀 攀砀椀猀琀猀 圀圀倀一✀猀Ⰰ愀渀搀 眀栀愀琀 攀砀愀挀琀氀礀 愀爀攀 琀栀攀礀㼀㰀戀爀㸀ഀഀ And, why, in some OS'ses, do we see device files like "/dev/rdsk/c0t0d0s0"? And, what is is a thing like EFI,
਍愀 ∀搀攀瘀椀挀攀 琀爀攀攀∀ 愀渀搀 猀琀甀昀昀Ⰰ 愀渀搀 椀渀搀攀攀搀Ⰰ 栀漀眀 搀漀攀猀 渀瘀爀愀洀 漀爀 昀椀爀洀眀愀爀攀 瀀氀愀礀 愀 爀漀氀攀 椀渀 昀椀渀搀椀渀最 猀琀漀爀愀最攀㼀㰀戀爀㸀ഀഀ
਍一甀洀洀攀爀漀甀猀 漀琀栀攀爀 焀甀攀猀琀椀漀渀猀 攀砀椀猀琀猀 漀昀挀漀甀爀猀攀⸀ 一漀眀Ⰰ 琀栀椀猀 猀椀洀瀀氀攀 渀漀琀攀 洀椀最栀琀 栀攀氀瀀 甀猀 椀渀 甀渀搀攀爀猀琀愀渀搀椀渀最㰀戀爀㸀ഀഀ some of the answers to those questions.
਍㰀戀爀㸀ഀഀ However, the material presented here, really is supersimple. Sometimes, to understand something completely,
਍礀漀甀 爀攀愀氀氀礀 栀愀瘀攀 渀漀 漀琀栀攀爀 漀瀀琀椀漀渀 琀栀愀渀 琀漀 ∀搀椀瘀攀 搀攀攀瀀∀ 椀渀琀漀 猀漀洀攀 瀀爀漀琀漀挀漀氀⸀㰀戀爀㸀ഀഀ In contrast, this note, keeps a very High-Level view at all times.
਍㰀戀爀㸀ഀഀ Also, there is no special focus on any specific type of architecture.
਍㰀戀爀㸀ഀഀ Next I need to apologize for the very simplistic pictures in this note. There are many professional figures
਍漀渀 琀栀攀 椀渀琀攀爀渀攀琀Ⰰ 戀甀琀 椀琀✀猀 渀漀琀 愀氀眀愀礀猀 挀氀攀愀爀 眀栀椀挀栀 愀爀攀 ∀昀爀攀攀∀ 琀漀 甀猀攀Ⰰ 猀漀 䤀 挀爀攀愀琀攀搀 愀 昀攀眀 洀礀猀攀氀昀⸀ 䐀漀渀✀琀 氀愀甀最栀 㬀ⴀ⤀㰀戀爀㸀ഀഀ
਍㰀戀爀㸀ഀഀ
਍ഀഀ ਍㰀栀爀⼀㸀ഀഀ

Chapter 1. A GENERIC (BUT INCOMPLETE) OS MODEL.

਍㰀栀爀⼀㸀ഀഀ ਍ഀഀ We must start "somewhere". So, maybe it's a good idea to see first which parts in the Operating System (OS)
਍栀愀瘀攀 猀漀洀攀 爀攀氀愀琀椀漀渀 琀漀 昀椀渀搀椀渀最 愀渀搀 愀挀挀攀猀猀椀渀最 猀琀漀爀愀最攀⸀㰀戀爀㸀ഀഀ
਍匀甀瀀瀀漀猀攀 愀 甀猀攀爀 愀瀀瀀氀椀挀愀琀椀漀渀 眀愀渀琀猀 琀漀 漀瀀攀渀 愀 昀椀氀攀Ⰰ 眀栀椀挀栀 攀砀椀猀琀猀 ∀猀漀洀攀眀栀攀爀攀∀ 漀渀 ∀猀漀洀攀 猀漀爀琀 漀昀 猀琀漀爀愀最攀∀⸀㰀戀爀㸀ഀഀ So, we could have a user who uses an editor, and wants to open some "readme" file on some
਍昀椀氀攀猀礀猀琀攀洀Ⰰ 猀愀礀Ⰰ 愀 搀椀爀攀挀琀漀爀礀 猀漀洀攀眀栀攀爀攀 椀渀 琀栀攀 ∀⼀栀漀洀攀∀ 昀椀氀攀猀礀猀琀攀洀⸀㰀戀爀㸀ഀഀ Note that in this case, it is "known" to the OS what the type of the filesystem is (like JFS, ext3 etc..)
਍㰀戀爀㸀ഀഀ Typically, the applications uses a "fopen()" systemcall, which will be handled by the "system call interface",
਍⠀猀漀爀琀 漀昀 愀瀀椀⤀Ⰰ 愀渀搀 琀栀攀 爀攀焀甀攀猀琀 眀椀氀氀 戀攀 瀀愀猀猀攀搀 漀渀 琀漀 琀栀攀 欀攀爀渀攀氀⸀㰀戀爀㸀ഀഀ
਍倀氀攀愀猀攀 琀愀欀攀 愀 氀漀漀欀 愀琀 昀椀最甀爀攀 ㄀⸀ 㰀戀爀㸀ഀഀ
਍吀栀攀 欀攀爀渀攀氀 栀愀猀 洀愀渀礀 攀猀猀攀渀琀椀愀氀 琀愀猀欀猀 氀椀欀攀 瀀爀漀挀攀猀猀 洀愀渀愀最攀洀攀渀琀 愀渀搀 琀栀攀 氀椀欀攀Ⰰ 愀渀搀 椀琀 眀椀氀氀㰀戀爀㸀ഀഀ hand off the request to a specialized 'IO Manager' (which in fact is a very generalized concept).
਍匀椀渀挀攀 琀栀攀爀攀 愀爀攀 猀漀 洀愀渀礀 琀礀瀀攀猀 漀昀 ∀昀椀氀攀猀礀猀琀攀洀猀∀Ⰰ 琀栀椀猀 洀漀搀甀氀攀 爀攀愀氀氀礀 甀猀攀猀 愀 猀漀爀琀 漀昀 ∀瀀氀甀最 愀渀搀 瀀氀愀礀∀ 挀漀渀挀攀瀀琀⸀㰀戀爀㸀ഀഀ In our "generic" OS, "a close friend" of the IO Manager, namely the "Virtual Filesystem", will use (or if neccessary load),
਍愀渀礀 猀瀀攀挀椀昀椀挀 洀漀搀甀氀攀 眀栀椀挀栀 挀愀渀 搀攀愀氀 眀椀琀栀 愀 挀攀爀琀愀椀渀 猀瀀攀挀椀昀椀挀 昀椀氀攀猀礀琀攀洀⸀㰀戀爀㸀ഀഀ
਍匀漀Ⰰ 猀甀瀀瀀漀猀攀 琀栀攀 嘀椀爀琀甀愀氀 䘀椀氀攀猀礀猀琀攀洀 栀愀猀 搀攀琀攀爀洀椀渀攀搀 琀栀愀琀 琀栀攀 甀猀攀爀 愀瀀瀀氀椀挀愀琀椀漀渀 愀挀琀甀愀氀氀礀 眀愀渀琀猀 琀漀 愀挀挀攀猀猀㰀戀爀㸀ഀഀ an "ext3" filesystem, then it will put the corresponding "ext3" driver/module at work, and it won't use
਍琀栀攀 一吀䘀匀 愀渀搀 䨀䘀匀 洀漀搀甀氀攀猀 ⠀猀椀渀挀攀 琀栀攀礀 愀爀攀 渀漀琀 漀昀 甀猀攀 栀攀爀攀⤀⸀㰀戀爀㸀ഀഀ Note that some number of those modules might thus already be loaded, ready for use.
਍㰀戀爀㸀ഀഀ Fig 1. Simplified storage driver stack in a model OS.
਍㰀戀爀㸀ഀഀ ਍㰀戀爀㸀ഀഀ
਍一漀眀Ⰰ 琀栀椀猀 猀瀀攀挀椀昀椀挀 昀椀氀攀猀礀猀琀攀洀 搀爀椀瘀攀爀 欀渀漀眀猀 愀氀氀 ∀椀渀 愀渀搀 漀甀琀猀∀ 漀昀 琀栀愀琀 猀瀀攀挀椀昀椀挀 昀椀氀攀猀礀猀琀攀洀Ⰰ 氀椀欀攀㰀戀爀㸀ഀഀ locking behaviour and types of access etc... but, it cannot retreive the file all by itself since it does not have
਍愀 挀氀甀攀 漀昀 琀栀攀 琀爀甀攀 瀀栀礀猀椀挀愀氀 瀀愀琀栀⸀㰀戀爀㸀ഀഀ That's why more specialized modules are set in action. Some are helper modules, but the last one in the stack
਍爀攀愀氀氀礀 ∀欀渀漀眀猀∀ 栀漀眀 琀漀 愀挀挀攀猀猀 琀栀攀 䠀漀猀琀 䈀甀猀琀 䄀搀愀瀀琀攀爀 ⠀䠀䈀䄀⤀Ⰰ 椀昀 琀栀攀 昀椀氀攀 琀栀愀琀 琀栀攀 甀猀攀爀 愀瀀瀀氀椀挀愀琀椀漀渀 眀愀渀琀猀Ⰰ 栀愀瀀瀀攀渀猀 琀漀 爀攀猀椀搀攀猀 猀漀洀攀眀栀攀爀攀㰀戀爀㸀ഀഀ on a Fiber Channel (FC) SAN.
਍䤀昀 愀渀漀琀栀攀爀 琀礀瀀攀 漀昀 猀琀漀爀愀最攀 渀攀攀搀攀搀 琀漀 戀攀 愀挀挀攀猀猀攀搀Ⰰ 氀椀欀攀 椀匀䌀匀䤀Ⰰ 愀渀漀琀栀攀爀 猀瀀攀挀椀愀氀椀稀攀搀 猀攀琀 漀昀 搀爀椀瘀攀爀猀 眀愀猀 甀猀攀搀⸀㰀戀爀㸀ഀഀ
਍伀甀爀 最攀渀攀爀椀挀 伀匀 洀漀搀攀氀 挀愀渀渀漀琀 戀攀 猀漀 戀愀搀 椀渀搀攀攀搀⸀ 吀愀欀攀 愀 氀漀漀欀 愀琀 昀椀最甀爀攀 ㈀⸀ 䠀攀爀攀 眀攀 猀攀攀 愀 猀椀洀椀氀愀爀 猀琀愀挀欀㰀戀爀㸀ഀഀ but this time of a real OS. Figure 2 shows you (very high-level !) how it is implemented in Windows.
਍㰀戀爀㸀ഀഀ
਍㰀䈀㸀䘀椀最 ㈀⸀ 匀椀洀瀀氀椀昀椀攀搀 猀琀漀爀愀最攀 搀爀椀瘀攀爀 猀琀愀挀欀 椀渀 圀椀渀搀漀眀猀⸀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
਍㰀椀洀最 猀爀挀㴀∀搀椀猀欀搀攀瘀椀挀攀猀㈀⸀樀瀀最∀ 愀氀椀最渀㴀∀挀攀渀琀爀攀∀⼀㸀ഀഀ
਍㰀戀爀㸀ഀഀ Here too, we see a Virtual Filesystem (VFS), which can utilise specialised modules for a specific filesystem type.
਍䤀渀 昀椀最甀爀攀 ㈀Ⰰ 礀漀甀 挀愀渀 猀攀攀 琀栀攀 ∀渀琀昀猀∀Ⰰ ∀昀愀琀∀ 愀渀搀 漀琀栀攀爀 猀瀀攀挀椀愀氀椀稀攀搀 洀漀搀甀氀攀猀⸀㰀戀爀㸀ഀഀ
਍吀栀攀 倀愀爀琀椀琀椀漀渀 䴀愀渀愀最攀爀Ⰰ ∀瀀愀爀琀洀最爀⸀猀礀猀∀Ⰰ 愀洀漀渀最 漀琀栀攀爀 琀愀猀欀猀Ⰰ 欀攀攀瀀猀 琀爀愀挀欀 漀昀 瀀愀爀琀椀琀椀漀渀猀 愀渀搀 䰀唀一猀 愀渀搀 洀愀欀攀猀 猀甀爀攀㰀戀爀㸀ഀഀ that their "identity" stays the same (like an F: drive stays the F: drive, also after a reboot).
਍㰀戀爀㸀ഀഀ Next, "storport.sys" is a general acces module for any type of remote storage.
਍䤀琀✀猀 琀栀攀 昀漀氀氀漀眀 甀瀀 漀昀 琀栀攀 昀漀爀洀攀爀 ∀猀挀猀椀瀀漀爀琀∀ 洀漀搀甀氀攀⸀ 匀琀漀爀瀀漀爀琀 椀猀 愀渀 㰀䈀㸀椀渀琀攀爀昀愀挀攀㰀⼀䈀㸀 戀攀琀眀攀攀渀 栀椀最栀攀爀 氀攀瘀攀氀 洀漀搀甀氀攀猀Ⰰ㰀戀爀㸀ഀഀ and the lower level "miniport" drivers. It deals with many tasks like queueing, error messages etc..
਍㰀戀爀㸀ഀഀ If we get lower in the stack, we will end up with specialized modules which knows how to handle
਍昀漀爀 攀砀愀洀瀀氀攀 愀 渀攀琀挀愀爀搀 ⠀昀漀爀 椀匀䌀匀䤀⤀ 漀爀 愀 䠀䈀䄀 ⠀昀漀爀 愀挀挀攀猀猀椀渀最 愀 䘀䌀 匀䄀一⤀⸀㰀戀爀㸀ഀഀ ਍㰀戀爀㸀ഀഀ
਍㰀戀爀㸀ഀഀ ਍㰀栀爀⼀㸀ഀഀ

Chapter 2. The Device Tree & firmware pre-boot implementations.

਍㰀栀爀⼀㸀ഀഀ ਍ഀഀ This chapter takes a look at possible pre-boot implementations (like Device Tree & firmware) with respect
਍琀漀 㰀䈀㸀戀漀漀琀椀渀最 愀 䠀漀猀琀㰀⼀䈀㸀⸀ 一漀眀Ⰰ 眀栀愀琀攀瘀攀爀 伀瀀攀爀愀琀椀渀最 匀礀猀琀攀洀 昀漀氀氀漀眀猀 愀昀琀攀爀 琀栀椀猀 ∀瀀爀攀 戀漀漀琀∀ 椀猀 愀挀琀甀愀氀氀礀 漀昀 渀漀 挀漀渀挀攀爀渀 栀攀爀攀⸀㰀戀爀㸀ഀഀ Ofcourse, it is important for the full picture, but here we do not really distinguish between
਍愀 䠀漀猀琀 眀栀椀挀栀 椀猀 愀猀 琀栀攀 昀甀氀氀 戀漀漀琀 攀渀搀猀Ⰰ 椀猀 ∀樀甀猀琀∀ 愀渀 伀瀀攀爀愀琀椀渀最 匀礀猀琀攀洀Ⰰ 漀爀 愀渀 伀匀 琀栀愀琀 椀猀 琀栀攀 戀愀猀椀猀 昀漀爀㰀戀爀㸀ഀഀ supporting "Virtual Machines" (VMs).
਍㰀戀爀㸀ഀഀ So, for practical purposes, view this chapter as a description of "bare metal machine" boot.
਍䤀渀 愀 氀愀琀攀爀 挀栀愀瀀琀攀爀Ⰰ 眀攀 眀椀氀氀 猀攀攀 洀漀爀攀 漀昀 愀 戀漀漀琀 漀昀 愀 䠀礀瀀攀爀瘀椀猀漀爀ⴀ氀椀欀攀 洀愀挀栀椀渀攀Ⰰ 眀栀椀挀栀 渀愀琀椀瘀攀氀礀 椀猀 洀攀愀渀琀 琀漀 猀甀瀀瀀漀爀琀 嘀䴀猀⸀ 㰀戀爀㸀ഀഀ ਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
਍㰀戀爀㸀ഀഀ ਍䤀琀✀猀 椀渀琀攀爀攀猀琀椀渀最 琀漀 猀攀攀 眀栀愀琀 ∀攀渀琀椀琀礀∀ 愀挀琀甀愀氀氀礀 搀椀猀挀漀瘀攀爀猀 戀甀猀攀猀Ⰰ 愀渀搀 搀攀瘀椀挀攀猀 漀渀 琀栀漀猀攀 戀甀猀攀猀⸀㰀戀爀㸀ഀഀ But it severly depends on the architecture.
਍㰀戀爀㸀ഀഀ I think it would be quite reasonble if you would have the idea that when your OS boots, it fully scans
਍琀栀攀 挀漀洀瀀甀琀攀爀 琀漀 昀椀渀搀 漀甀琀 ∀眀栀愀琀✀猀 椀渀 琀栀攀爀攀∀Ⰰ 愀渀搀 挀漀渀昀椀最甀爀攀 琀栀攀 猀礀猀琀攀洀 愀挀挀漀爀搀椀渀最氀礀⸀㰀戀爀㸀ഀഀ
਍夀攀猀 愀渀搀 一漀⸀ 䤀 欀渀漀眀 琀栀愀琀 ∀礀攀猀 愀渀搀 渀漀∀ 搀漀攀猀 渀漀琀 猀漀甀渀搀 最漀漀搀Ⰰ 戀甀琀 椀琀 椀猀 琀栀攀 琀爀甀琀栀⸀㰀戀爀㸀ഀഀ
਍倀氀攀愀猀攀 戀攀 愀眀愀爀攀 琀栀愀琀 䤀✀愀洀 渀漀琀 猀愀礀椀渀最 琀栀愀琀 愀渀 伀匀 搀漀攀猀 渀漀琀 栀愀瘀攀 ∀瀀漀氀氀椀渀最⼀攀渀甀洀洀愀爀愀琀漀爀 昀攀愀琀甀爀攀猀∀⸀ 䌀攀爀琀愀椀渀氀礀 渀漀琀⸀㰀戀爀㸀ഀഀ It's only that for certain platforms, device trees can be build by "firmware like" solutions, immediately after power-on
਍漀昀 猀甀挀栀 愀 猀礀猀琀攀洀⸀ 唀猀甀愀氀氀礀Ⰰ 猀甀挀栀 愀 昀椀爀洀眀愀爀攀 猀漀氀甀琀椀漀渀 椀猀 愀挀挀漀洀瀀愀渀椀攀搀 戀礀 愀 ∀猀栀攀氀氀∀ 眀椀琀栀 愀 爀攀氀愀琀椀瘀攀氀礀 挀漀洀瀀愀挀琀 挀漀洀洀愀渀搀猀攀琀Ⰰ㰀戀爀㸀ഀഀ which enables the admin the view/walk the tree, map devices, probe for devices, and ofcourse, boot an OS.
਍㰀戀爀㸀ഀഀ Ofcourse, in general terms, if you get a kernel (and the rest of an OS), it's meant for a certain architecture.
਍圀攀 愀氀氀 甀渀搀攀爀猀琀愀渀搀 琀栀愀琀Ⰰ 猀愀礀Ⰰ 樀甀猀琀 猀漀洀攀 䰀椀渀甀砀 搀椀猀琀爀漀 昀漀爀 䤀渀琀攀氀 砀㠀㘀Ⰰ 眀椀氀氀 渀漀琀 爀甀渀 甀渀洀漀搀椀昀椀攀搀 漀渀 漀琀栀攀爀 瀀氀愀琀昀漀爀洀猀⸀㰀戀爀㸀ഀഀ
਍䈀甀琀 琀栀攀爀攀 椀猀 愀 戀椀琀 洀漀爀攀 琀漀 椀琀⸀ 䔀瘀攀渀 昀漀爀 愀 㰀䤀㸀挀攀爀琀愀椀渀 愀爀挀栀椀琀攀挀琀甀爀攀Ⰰ㰀⼀䤀㸀 琀栀攀爀攀 洀椀最栀琀 攀砀椀猀琀猀 洀愀渀礀 洀愀椀渀戀漀愀爀搀猀 甀猀椀渀最㰀戀爀㸀ഀഀ different buses and interconnects. Engineers and other IT folks, never liked the idea of creating
਍愀 猀甀瀀攀爀栀攀愀瘀礀 欀攀爀渀攀氀 眀栀椀挀栀 椀猀 瀀爀攀瀀愀爀攀搀 昀漀爀 愀氀氀 猀漀爀琀猀 漀昀 洀愀椀渀戀漀愀爀搀猀 愀渀搀 琀栀攀 洀椀爀椀愀搀 漀昀 瀀漀猀猀椀戀氀攀 搀攀瘀椀挀攀猀㰀戀爀㸀ഀഀ on all sorts of buses.
਍吀栀攀 瀀爀漀戀氀攀洀 椀猀 挀氀攀愀爀㨀 栀漀眀 挀愀渀 眀攀 氀攀琀 琀栀攀 伀匀 爀攀挀欀漀最渀椀稀攀 愀氀氀 戀甀猀攀猀 愀渀搀 搀攀瘀椀挀攀猀Ⰰ 愀渀搀 戀椀渀搀 搀爀椀瘀攀爀猀 琀漀 琀栀漀猀攀㰀戀爀㸀ഀഀ devices? One solution might be: build a kernel with lots of tables or configuration databases.
਍䤀渀 愀渀 伀瀀攀渀 䤀渀搀甀猀琀爀礀Ⰰ 琀栀椀猀 眀愀猀 渀攀瘀攀爀 瀀攀爀挀攀椀瘀攀搀 愀猀 愀 瘀椀愀戀氀攀 猀漀氀甀琀椀漀渀⸀㰀戀爀㸀ഀഀ
਍ഀഀ That's why some "solutions" were presented already quite some time ago, and some newer followup protocols were constructed,
਍氀椀欀攀 ∀伀瀀攀渀 昀椀爀洀眀愀爀攀∀Ⰰ 䄀䌀倀䤀 愀渀搀 唀䔀䘀䤀⸀㰀戀爀㸀ഀഀ ਍㰀戀爀㸀ഀഀ
਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀爀攀搀∀㸀ഀഀ ਍㰀栀㌀㸀 ㈀⸀㄀ 䔀愀爀氀礀 昀椀爀洀眀愀爀攀ⴀ氀椀欀攀 猀漀氀甀琀椀漀渀猀⸀㰀⼀栀㌀㸀ഀഀ ਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ ਍䄀氀爀攀愀搀礀 焀甀椀琀攀 攀愀爀氀礀Ⰰ 猀漀洀攀 昀椀爀洀眀愀爀攀ⴀ氀椀欀攀 猀漀氀甀琀椀漀渀猀 眀攀爀攀 椀洀瀀氀攀洀攀渀琀攀搀Ⰰ 氀椀欀攀 昀漀爀 攀砀愀洀瀀氀攀 伀瀀攀渀戀漀漀琀 昀漀爀 匀甀渀 匀瀀愀爀挀 洀愀挀栀椀渀攀猀⸀㰀戀爀㸀ഀഀ Openboot might be considered to be an "early" Open firmware implementation.
਍㰀戀爀㸀ഀഀ It was partly a "PROM" and "NVRAM" solution, where at "power on", a socalled "device tree" was build first,
਍戀攀昀漀爀攀 琀栀攀 伀匀 戀漀漀琀猀 ⠀氀椀欀攀 匀漀氀愀爀椀猀 㠀 椀渀 琀栀漀猀攀 搀愀礀猀⤀⸀㰀戀爀㸀ഀഀ The associated code was written in Forth, and the NVRAM could store all sorts of variables like if
਍愀甀琀漀戀漀漀琀 ⠀琀漀 匀漀氀愀爀椀猀⤀ 眀愀猀 琀爀甀攀Ⰰ 愀渀搀 猀漀 昀漀爀琀栀⸀㰀戀爀㸀ഀഀ A short time after the power was put on, the Admin had the choiche to boot to the OS, or just stay
਍愀琀 琀栀攀 ∀伀瀀攀渀戀漀漀琀∀ 瀀爀漀洀瀀琀Ⰰ 甀猀甀愀氀氀礀 瘀椀猀椀戀氀攀 漀渀 琀栀攀 挀漀渀猀漀氀攀 愀猀 愀 ∀漀欀㸀∀ 瀀爀漀洀瀀琀⸀㰀戀爀㸀ഀഀ On this prompt, if the Admin wanted to do so, he could traverse the Device Tree (showing what was in there),
਍漀爀 攀瘀攀渀 ∀瀀爀漀戀攀∀ 昀漀爀 渀攀眀氀礀 椀渀猀琀愀氀氀攀搀 搀攀瘀椀挀攀猀⸀㰀戀爀㸀ഀഀ
਍圀攀 猀栀漀甀氀搀 渀漀琀 猀琀愀礀 琀漀漀 氀漀渀最 愀琀 琀栀椀猀 瀀愀爀琀椀挀甀氀愀爀 椀洀瀀氀攀洀攀渀琀愀琀椀漀渀Ⰰ 戀甀琀 䤀 眀愀渀琀 礀漀甀 欀渀漀眀 琀栀愀琀 愀氀爀攀愀搀礀 愀琀㰀戀爀㸀ഀഀ the "ok>" prompt, address paths to devices were visible. And a key point of the story is, that the Device Tree,
਍愀 搀愀琀愀猀琀爀甀挀琀甀爀攀 椀渀 洀攀洀漀爀礀Ⰰ 眀愀猀 瀀愀猀猀攀搀 漀渀 琀漀 琀栀攀 欀攀爀渀攀氀 眀栀攀渀 椀琀 戀漀漀琀猀Ⰰ 愀渀搀 眀栀攀爀攀 琀栀攀 欀攀爀渀攀氀 渀攀砀琀 眀愀猀 愀戀氀攀 㰀戀爀㸀ഀഀ to build "friendly" names in "/dev" while the device tree was still visible (and mounted) in "/devices".
਍匀漀Ⰰ 渀漀琀攀 琀栀愀琀 琀栀攀 欀攀爀渀攀氀 甀猀攀猀 琀栀椀猀 搀愀琀愀猀琀爀甀挀琀甀爀攀Ⰰ 琀漀 欀渀漀眀 搀攀瘀椀挀攀猀 愀渀搀 琀漀 洀漀爀攀 攀愀猀椀氀礀 戀椀渀搀 搀爀椀瘀攀爀猀㰀戀爀㸀ഀഀ and configure the system.
਍㰀戀爀㸀ഀഀ Here is an example of such a physical address path:
਍㰀戀爀㸀ഀഀ ਍ഀഀ /pci@1f,0/pci@1/isptwo@4/sd@2,0
਍ഀഀ ਍㰀戀爀㸀ഀഀ Such a path actually can be seen as a "root node" where a hierarchy of "sub/child nodes" resides,
਍甀氀琀椀洀愀琀攀氀礀 攀渀搀椀渀最 椀渀 搀攀瘀椀挀攀猀⸀ 䤀渀 琀栀攀 攀砀愀洀瀀氀攀 愀戀漀瘀攀Ⰰ 眀攀 猀攀攀 愀 瀀愀琀栀 琀漀 愀 匀䌀匀䤀 搀椀猀欀Ⰰ 昀爀漀洀 愀 氀漀挀愀氀 匀䌀匀䤀 挀漀渀琀爀漀氀氀攀爀㰀戀爀㸀 ഀഀ in a PCI slot.
਍㰀戀爀㸀ഀഀ Actually, a key point here, is that devices, also storage devices, might be found at a firmware boot,
਍眀栀攀爀攀 椀琀 最攀琀猀 愀猀猀猀漀挀椀愀琀攀搀 眀椀琀栀 愀渀 愀搀搀爀攀猀猀 瀀愀琀栀 ⠀愀 ∀瀀栀礀猀椀挀愀氀 搀攀瘀椀挀攀 渀愀洀攀∀ 椀昀 礀漀甀 氀椀欀攀⤀Ⰰ 愀渀搀 猀甀戀猀攀焀甀攀渀氀礀 琀栀攀 欀攀爀渀攀氀㰀戀爀㸀ഀഀ uses that info further for configuration.
਍ഀഀ
਍㰀戀爀㸀ഀഀ ਍ഀഀ

2.2 Open Firmware:

਍ഀഀ ਍ഀഀ ਍圀栀椀氀攀 匀甀渀✀猀 昀漀爀洀攀爀 㰀䈀㸀∀伀瀀攀渀戀漀漀琀∀㰀⼀䈀㸀 洀椀最栀琀 戀攀 挀漀渀猀椀搀攀爀攀搀 琀漀 戀攀 愀 瀀爀攀搀攀挀攀猀猀漀爀Ⰰ 㰀䈀㸀∀伀瀀攀渀 昀椀爀洀眀愀爀攀∀㰀⼀䈀㸀 愀猀 椀猀 椀琀 椀猀 渀漀眀 挀愀氀氀攀搀Ⰰ 猀栀漀甀氀搀 戀攀 猀攀攀渀 愀猀 愀㰀戀爀㸀ഀഀ non-proprietary boot firmware that might be implemented on various platforms or architectures.
਍㰀戀爀㸀ഀഀ ⇒ For example, the CHRP Specification (Common Hardware Reference Platform) requires the use of Open Firmware.
਍䔀砀愀洀瀀氀攀猀 愀爀攀 琀栀攀 倀漀眀攀爀ⴀ 愀渀搀 倀漀眀攀爀倀䌀 愀爀挀栀椀琀攀挀琀甀爀攀猀 漀昀 䤀䈀䴀⸀㰀戀爀㸀ഀഀ No doubt that "system p" and "system i" Admins, know of the "ok>" prompt which can be accessed through the SMS Boot Menu.
਍吀栀攀猀攀 愀爀攀 琀栀攀  洀漀搀攀爀渀 䄀䤀堀 愀渀搀 䄀匀㐀　　 ⠀漀氀搀 琀攀爀洀⤀ 洀愀挀栀椀渀攀猀Ⰰ 挀愀瀀愀戀氀攀 漀昀 爀甀渀渀椀渀最 䄀䤀堀Ⰰ 䤀 ⠀䄀匀㐀　　⤀Ⰰ 愀渀搀 䰀椀渀甀砀 嘀䴀✀猀⸀㰀戀爀㸀ഀഀ
਍☀⌀㠀㘀㔀㠀㬀 䄀氀猀漀Ⰰ 礀漀甀 眀椀氀氀 渀漀琀 戀攀 猀甀爀瀀爀椀猀攀搀 琀栀愀琀 匀甀渀 洀愀挀栀椀渀攀猀 甀猀攀猀 愀渀 伀瀀攀渀 昀椀爀洀眀愀爀攀 椀洀瀀氀洀攀渀琀愀琀椀漀渀 琀漀漀⸀ ⠀匀甀渀 栀愀猀 戀攀攀渀 ∀攀愀琀攀渀∀ 戀礀 伀爀愀挀氀攀⤀⸀㰀戀爀㸀ഀഀ
਍☀⌀㠀㘀㔀㠀㬀 䤀渀 挀漀渀琀爀愀猀琀Ⰰ 愀猀 礀漀甀 瀀爀漀戀愀戀氀礀 欀渀漀眀Ⰰ 䤀渀琀攀氀 戀愀猀攀搀 砀㠀㘀⼀㘀㐀 洀愀挀栀椀渀攀猀 甀猀甀愀氀氀礀 甀猀攀搀 琀漀 甀猀攀 倀䌀 䈀䤀伀匀 椀洀瀀氀攀洀攀渀琀愀琀椀漀渀猀⸀㰀戀爀㸀ഀഀ However, implementing ACPI is quite established, and on newer Intel/Windows Platforms, EFI can be used as well.
਍䴀漀爀攀 愀戀漀甀琀 琀栀愀琀 氀愀琀攀爀 漀渀⸀㰀戀爀㸀ഀഀ
਍夀漀甀 洀椀最栀琀 猀愀礀Ⰰ 琀栀愀琀 伀瀀攀渀 䘀爀椀爀洀眀愀爀攀 椀猀 瘀攀爀礀 攀昀昀攀挀琀椀瘀攀 昀漀爀 倀䌀䤀 搀攀瘀椀挀攀猀⸀ 伀瀀攀渀 昀椀爀洀眀愀爀攀 挀愀渀 戀攀 猀攀攀渀 愀猀 愀 戀漀漀琀 洀愀渀愀最攀爀Ⰰ 愀渀搀 眀栀攀渀 琀栀攀㰀戀爀㸀ഀഀ "minikernel" (so to speak) from firmware has booted, it can offer a shell with a limited commandset.
਍䄀搀搀椀琀椀漀渀愀氀氀礀Ⰰ 倀䌀䤀 搀攀瘀椀挀攀猀 洀椀最栀琀 戀攀 攀焀甀椀瀀攀搀 眀椀琀栀 䘀䌀漀搀攀 眀栀椀挀栀 攀渀愀戀氀攀猀 椀琀 琀漀 爀攀瀀漀爀琀 椀搀攀渀琀椀昀椀挀愀琀椀漀渀ⴀ 愀渀搀 爀攀猀漀甀爀挀攀 挀栀愀爀愀挀琀攀爀椀猀琀椀挀猀Ⰰ㰀戀爀㸀ഀഀ which Openfirmware can use to build the device tree.
਍唀猀甀愀氀氀礀Ⰰ 伀瀀攀渀 昀椀爀眀愀爀攀 漀昀昀攀爀猀 猀椀洀瀀氀攀 洀攀愀渀猀 琀漀 戀漀漀琀 琀栀攀 猀礀猀琀攀洀 琀漀 愀渀 伀匀 ⠀瀀漀猀猀椀戀氀礀 洀甀氀琀椀戀漀漀琀⤀ 眀栀椀挀栀 眀椀氀氀 甀猀攀 琀栀攀 搀攀瘀椀挀攀 琀爀攀攀 昀甀爀琀栀攀爀 昀漀爀 挀漀渀昀椀最甀爀愀琀椀漀渀㰀戀爀㸀ഀഀ and driver binding on devices.
਍㰀戀爀㸀ഀഀ
਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀爀攀搀∀㸀ഀഀ ਍㰀栀㌀㸀㈀⸀㌀ 䔀䘀䤀 漀爀 唀䔀䘀䤀㨀㰀⼀栀㌀㸀ഀഀ ਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ ਍䔀䘀䤀Ⰰ 漀爀 琀栀攀 㰀䈀㸀∀䔀砀琀攀渀猀椀戀氀攀 䘀椀爀洀眀愀爀攀 䤀渀琀攀爀昀愀挀攀∀㰀⼀䈀㸀Ⰰ 眀愀猀 䤀渀琀攀氀✀猀 椀搀攀愀 漀渀 爀攀瀀氀愀挀椀渀最 琀栀攀 琀爀愀搀椀琀椀漀渀愀氀 倀䌀 䈀䤀伀匀 猀礀猀琀攀洀猀⸀㰀戀爀㸀ഀഀ Formally, EFI "evolved" into the "Unified EFI Platform Initialization" specifications. So, from now on we will use the term UEFI
਍琀漀 搀攀挀爀椀戀攀 琀栀椀猀 ∀渀攀眀∀ 䈀䤀伀匀ⴀ氀椀欀攀 昀漀氀氀漀眀甀瀀 瀀爀漀琀漀挀漀氀⸀㰀戀爀㸀ഀഀ
਍䤀✀愀洀 渀漀琀 猀愀礀椀渀最 琀栀愀琀 琀栀攀 䈀䤀伀匀 猀琀愀礀攀搀 攀砀愀挀琀氀礀 琀栀攀 猀愀洀攀 漀瘀攀爀 愀氀氀 琀栀漀猀攀 礀攀愀爀猀⸀ 䘀愀爀 昀爀漀洀 椀琀⸀ 吀栀攀 䈀䤀伀匀✀猀攀猀 昀爀漀洀 搀椀昀昀攀爀攀渀琀 瘀攀渀搀漀爀猀㰀戀爀㸀ഀഀ using more and more extensions, kept up with new hardware implementations. However, it was time for a fundamental change.
਍䘀漀爀 攀砀愀洀瀀氀攀Ⰰ 搀攀洀愀渀搀猀 昀漀爀 猀攀挀甀爀椀琀礀Ⰰ 戀攀琀琀攀爀 搀攀猀挀椀猀椀漀渀猀 戀礀 氀漀眀 氀攀瘀攀氀 猀漀昀琀眀愀爀攀 漀渀 猀氀攀攀瀀椀渀最 洀漀搀攀猀Ⰰ 戀攀琀琀攀爀 戀漀漀琀洀愀渀愀最攀爀猀Ⰰ 愀渀搀 洀漀爀攀㰀戀爀㸀ഀഀ control on the bootprocess (and maybe many more), probably all led to the UEFI implementation.
਍吀栀愀琀 椀猀 渀漀 琀漀 猀愀礀 琀栀愀琀 唀䔀䘀䤀 椀猀 ∀最爀攀愀琀∀⸀ 一漀Ⰰ 愀挀琀甀愀氀氀礀 椀琀✀猀 瘀攀爀礀 挀漀洀瀀氀攀砀Ⰰ 戀甀琀 愀琀 氀攀愀猀琀 椀琀 漀瘀攀爀挀漀洀攀猀 洀愀渀礀 氀椀洀椀琀愀琀椀漀渀猀⸀㰀戀爀㸀ഀഀ
਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀搀愀爀欀洀愀最攀渀琀愀∀㸀ഀഀ ਍一漀琀攀 琀栀愀琀 琀栀攀 㰀䈀㸀䜀唀䤀䐀 倀愀爀琀椀琀椀漀渀 吀愀戀氀攀 ⠀䜀倀吀⤀㰀⼀䈀㸀 眀愀猀 愀氀猀漀 椀渀琀爀漀搀甀挀攀搀 愀猀 瀀愀爀琀 漀昀 唀䔀䘀䤀Ⰰ 琀漀 漀瘀攀爀挀漀洀攀 琀栀攀 氀椀洀椀琀愀琀椀漀渀猀 漀昀 琀栀攀 䴀䈀刀㰀戀爀㸀ഀഀ partitioning scheme. However, in principle, you can use GPT without EFI, if it isn't a bootdisk.
਍ഀഀ ਍ ഀഀ
਍唀䔀䘀䤀 愀猀 椀琀 椀猀 渀漀眀Ⰰ 猀攀攀洀猀 琀漀 戀攀 琀椀攀搀 琀漀 䤀渀琀攀氀 渀攀眀攀猀琀 愀爀挀栀椀琀攀挀琀甀爀攀猀⸀ 一漀琀 洀攀愀渀椀渀最 琀栀愀琀 礀漀甀 渀漀眀 椀洀洀攀搀椀愀琀攀氀礀 琀栀椀渀欀 漀昀 圀椀渀搀漀眀猀㰀戀爀㸀ഀഀ Operating Systems perse. One nice example is HP systems based on Itanium". Ofcourse, HP hopes that you will boot to HP-UX
, ਍戀甀琀 䔀䘀䤀Ⰰ 猀攀攀渀 愀猀 愀 戀漀漀琀洀愀渀愀最攀爀Ⰰ 愀氀氀漀眀猀 礀漀甀 攀愀猀椀氀礀 琀漀 戀漀漀琀 琀漀 愀渀漀琀栀攀爀 伀匀 氀椀欀攀 刀攀搀䠀愀琀Ⰰ 匀甀猀攀Ⰰ 圀椀渀搀漀眀猀Ⰰ 攀琀挀⸀⸀㰀戀爀㸀ഀഀ
਍䘀漀爀 猀攀挀甀爀椀琀礀 攀砀瀀攀爀琀猀Ⰰ 琀栀攀 䔀䘀䤀 瀀爀攀 戀漀漀琀 攀渀瘀椀爀漀渀洀攀渀琀 挀漀甀氀搀 戀攀 猀攀攀渀 愀猀 愀 氀愀爀最攀 椀洀瀀爀漀瘀攀洀攀渀琀 琀漀漀⸀ 䤀渀 瀀爀椀渀挀椀瀀氀攀Ⰰ 瘀愀爀椀漀甀猀 昀漀爀洀猀 漀昀 愀甀琀栀攀渀琀椀挀愀琀椀漀渀㰀戀爀㸀ഀഀ are possible, as described in the "EFI pre-boot authentication protocol".
਍䄀猀 愀 猀椀搀攀渀漀琀攀㨀 䤀琀✀猀 愀氀猀漀Ⰰ 昀漀爀 攀砀愀洀瀀氀攀Ⰰ 焀甀椀琀攀 椀渀琀攀爀攀猀琀椀渀最 琀漀 爀攀愀搀 愀爀琀椀挀氀攀猀 漀渀 琀栀攀 㰀䈀㸀圀椀渀搀漀眀猀 㠀㰀⼀䈀㸀 ∀䔀愀爀氀礀 䰀愀甀渀挀栀 䄀渀琀椀ⴀ䴀愀氀眀愀爀攀∀ 椀洀瀀氀攀洀攀渀琀愀琀椀漀渀⸀㰀戀爀㸀ഀഀ
਍䤀渀 漀渀攀 猀攀渀琀攀渀挀攀㨀 䔀䘀䤀 椀猀 漀昀琀攀渀 搀攀昀椀渀攀搀 愀猀 愀渀 㰀䈀㸀椀渀琀攀爀昀愀挀攀㰀⼀䈀㸀 戀攀琀眀攀攀渀 愀渀 漀瀀攀爀愀琀椀渀最 猀礀猀琀攀洀 愀渀搀 瀀氀愀琀昀漀爀洀 昀椀爀洀眀愀爀攀⸀㰀戀爀㸀ഀഀ It's best to view EFI as a modular structure, consisting of "certain parts", like a firmware interface, a bootmanager,
਍愀渀 䔀䘀䤀 猀礀猀琀攀洀瀀愀爀琀椀琀椀漀渀Ⰰ 愀渀搀 猀甀瀀瀀漀爀琀 昀漀爀 愀 搀爀椀瘀攀爀洀漀搀攀氀 甀猀椀渀最 䔀䘀䤀 䈀礀琀攀 䌀漀搀攀 ⠀䔀䈀䌀⤀⸀㰀戀爀㸀ഀഀ
਍吀栀攀 栀愀爀搀眀愀爀攀 洀甀猀琀 戀攀 猀甀椀琀愀戀氀攀 昀漀爀 甀猀椀渀最 䔀䘀䤀Ⰰ 猀漀Ⰰ 爀攀愀氀氀礀 漀氀搀 砀㠀㘀 猀礀猀琀攀洀猀 愀爀攀 渀漀琀 甀猀愀戀氀攀Ⰰ 戀甀琀 砀㠀㘀 椀猀 渀漀琀 攀砀挀氀甀搀攀搀⸀㰀戀爀㸀ഀഀ However, if the hardware is supported, it is still possible (if you would insist) to run legacy BIOS Operating Systems,
਍∀琀栀愀渀欀猀∀ 琀漀 挀漀洀瀀愀琀椀戀椀氀椀琀礀 洀漀搀甀氀攀猀 氀椀欀攀 䌀匀䴀⸀ 䠀漀眀攀瘀攀爀Ⰰ 唀䔀䘀䤀 椀猀 琀愀爀最攀琀攀搀 昀漀爀 䈀䤀伀匀 昀爀攀攀 猀礀猀琀攀洀猀⸀㰀戀爀㸀ഀഀ
਍䄀昀琀攀爀 愀 猀礀猀琀攀洀 椀猀 瀀漀眀攀爀攀搀 漀渀Ⰰ 瘀攀爀礀 最氀漀戀愀氀氀礀Ⰰ 琀栀攀 昀漀氀氀漀眀椀渀最 栀愀瀀瀀攀猀㨀㰀戀爀㸀ഀഀ
਍䘀椀爀猀琀Ⰰ 猀漀洀攀 㰀䈀㸀猀礀猀琀攀洀 搀攀瀀攀渀搀攀渀琀 爀漀甀琀椀渀攀猀㰀⼀䈀㸀 愀爀攀 愀挀琀椀瘀愀琀攀搀Ⰰ 氀椀欀攀 昀漀爀 攀砀愀洀瀀氀攀 ∀䤀䴀䴀∀ 椀渀椀琀椀愀氀椀稀愀琀椀漀渀 漀渀 愀 䤀䈀䴀 匀礀猀琀攀洀 堀Ⰰ㰀戀爀㸀ഀഀ where at the last stage, UEFI code is called. So, each architecture uses it's own very specific initial routines.
਍㰀戀爀㸀ഀഀ Next, the Security (SEC) phase, Pre-EFI Initialization (PEI) phase, and then the Driver Execution Environment (DXE) phase
਍愀爀攀 攀砀攀挀甀琀攀搀 椀渀 猀攀焀甀攀渀挀攀⸀㰀戀爀㸀ഀഀ In reality, those phases are really pretty complex, but for our purposes, it not neccessary to go into the details.
਍㰀戀爀㸀ഀഀ During the DXE phase, EFI Byte Code drivers might be loaded from any firmware flash, or could come
਍昀爀漀洀 唀䔀䘀䤀ⴀ挀漀洀瀀氀椀愀渀琀 愀搀愀瀀琀攀爀猀⸀ 䄀 搀攀瘀椀挀攀 琀爀攀攀 椀猀 戀甀椀氀搀Ⰰ 昀漀爀 伀匀✀猀攀猀 琀栀愀琀 挀愀渀 甀猀攀 椀琀⸀㰀戀爀㸀ഀഀ
਍䰀愀猀琀氀礀Ⰰ 琀栀攀 ∀䈀漀漀琀 䐀攀瘀椀挀攀 匀攀氀攀挀琀椀漀渀∀ ⠀䈀䐀匀⤀ 琀愀欀攀猀 瀀氀愀挀攀Ⰰ 愀渀搀 琀栀攀 猀礀猀琀攀洀㨀ഀഀ

਍㰀氀椀㸀 洀椀最栀琀 戀攀 挀漀渀昀椀最甀爀攀搀 昀漀爀 ∀愀甀琀漀戀漀漀琀∀琀漀 猀漀洀攀 伀匀⸀㰀⼀氀椀㸀ഀഀ
• Or, the system might enter a "bootmenu"
਍㰀氀椀㸀伀爀 瀀漀猀猀椀戀氀礀 攀渀琀攀爀 琀栀攀 䔀䘀䤀 ∀匀栀攀氀氀∀⸀㰀⼀氀椀㸀ഀഀ

਍圀椀琀栀 爀攀猀瀀攀挀琀 琀漀 琀栀攀 愀甀琀漀戀漀漀琀㨀 樀甀猀琀 氀椀欀攀 眀椀琀栀 伀瀀攀渀 戀漀漀琀 漀爀 伀瀀攀渀 昀椀爀洀眀愀爀攀Ⰰ 一嘀刀䄀䴀 挀愀渀 猀琀漀爀攀 猀攀瘀攀爀愀氀 瘀愀爀椀愀戀氀攀猀Ⰰ㰀戀爀㸀ഀഀ like whether "autoboot" to some selected OS should take place.
਍㰀戀爀㸀ഀഀ From this point on, it gets interesting for us. Take a look please, at figure 3.
਍㰀戀爀㸀ഀഀ Fig 3. Simplified EFI boot sequence (on HP Itanium).
਍㰀戀爀㸀ഀഀ ਍㰀戀爀㸀ഀഀ
਍唀䔀䘀䤀 椀猀 愀 猀攀琀 漀昀 猀瀀攀挀椀昀椀挀愀琀椀漀渀猀 椀渀 琀攀挀栀渀椀挀愀氀 搀漀挀甀洀攀渀琀猀Ⰰ 戀甀琀 栀漀眀 椀琀Ⰰ 瀀攀爀 愀爀挀栀椀琀攀挀琀甀爀攀Ⰰ 眀椀氀氀 ∀氀漀漀欀 氀椀欀攀∀Ⰰ㰀戀爀㸀ഀഀ depends also a bit per manufacturer, I am afraid.
਍䠀漀眀攀瘀攀爀Ⰰ 猀漀洀攀琀栀椀渀最 挀愀氀氀攀搀 琀栀攀 㰀䈀㸀䔀䘀䤀 匀礀猀琀攀洀 瀀愀爀琀椀琀椀漀渀㰀⼀䈀㸀 ⠀䔀匀倀⤀ 爀攀愀氀氀礀 椀猀 瀀愀爀琀 漀昀 琀栀攀 䔀䘀䤀 猀瀀攀挀猀⸀㰀戀爀㸀  ഀഀ Note the existence of the EFI System partition in figure 3.
਍㰀戀爀㸀ഀഀ Example 1: HP on Itanium using EFI:
਍㰀戀爀㸀ഀഀ Figure 3 tries to show the Itanium implementation, as is often used by HP.
਍䄀昀琀攀爀 琀栀攀 䔀䘀䤀 氀愀甀渀挀栀Ⰰ 礀漀甀 洀椀最栀琀 攀渀琀攀爀 愀 㰀䈀㸀戀漀漀琀洀攀渀甀㰀⼀䈀㸀Ⰰ 漀爀 愀 㰀䈀㸀匀栀攀氀氀㰀⼀䈀㸀 眀栀攀爀攀 礀漀甀 挀愀渀 甀猀攀 愀 猀洀愀氀氀 挀漀洀洀愀渀搀猀攀琀㰀戀爀㸀 ഀഀ like "cd", "map" etc..
਍吀栀椀猀 猀礀猀琀攀洀 瀀愀爀琀椀琀椀漀渀Ⰰ 椀猀 椀渀搀攀攀搀 樀甀猀琀 愀 瀀愀爀琀椀琀椀漀渀 ⠀氀椀欀攀氀礀 琀漀 戀攀 漀渀 搀椀猀欀　⤀ 愀渀搀 椀琀✀猀 漀昀 愀 䘀䄀吀 昀椀氀攀猀礀猀琀攀洀 琀礀瀀攀⸀㰀戀爀㸀ഀഀ
਍䐀漀 礀漀甀 渀漀琀椀挀攀 琀栀攀 ∀尀䔀䘀䤀∀ 洀愀椀渀 搀椀爀攀挀琀漀爀礀Ⰰ 愀渀搀 琀栀攀 猀甀戀搀椀爀攀挀琀漀爀椀攀猀 氀椀欀攀 昀漀爀 攀砀愀洀瀀氀攀 ∀尀䔀䘀䤀尀刀攀搀栀愀琀∀㼀㰀戀爀㸀ഀഀ Each such subdir contains a specific "OS loader" for that specific OS.
਍夀漀甀 挀愀渀 猀攀攀 猀甀挀栀 氀漀愀搀攀爀猀 戀礀 攀渀琀攀爀椀渀最 琀栀攀 ∀匀栀攀氀氀∀ 昀猀　㸀 愀渀搀 渀愀瘀椀最愀琀攀 愀爀漀甀渀搀 愀 戀椀琀⸀ 䔀砀愀洀瀀氀攀 氀漀愀搀攀爀猀 挀漀甀氀搀 戀攀 昀椀氀攀猀 氀椀欀攀㨀㰀戀爀㸀ഀഀ
਍㰀䈀㸀∀尀䔀䘀䤀尀瘀洀猀尀瘀洀猀开氀漀愀搀攀爀⸀攀昀椀∀㰀戀爀㸀ഀഀ
਍漀爀㰀戀爀㸀ഀഀ
਍∀尀䔀䘀䤀尀爀攀搀栀愀琀尀攀氀椀氀漀⸀攀昀椀∀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
਍吀栀攀 愀挀琀甀愀氀 欀攀爀渀攀氀 漀昀 愀渀 伀匀Ⰰ 眀椀氀氀 爀攀猀椀搀攀 漀渀 愀渀漀琀栀攀爀 瀀愀爀琀椀琀椀漀渀Ⰰ 瀀漀猀猀椀戀氀礀 愀 瀀愀爀琀椀琀椀漀渀 漀渀 愀渀漀琀栀攀爀 搀椀猀欀猀礀猀琀攀洀⸀㰀戀爀㸀ഀഀ
਍吀栀椀猀 攀砀瀀氀愀椀渀猀 眀栀礀 栀攀爀攀 漀渀 䤀琀愀渀椀甀洀Ⰰ 洀甀氀琀椀戀漀漀琀 椀猀 瀀漀猀猀椀戀氀攀⸀ 䈀礀 琀栀攀 眀愀礀Ⰰ 琀栀攀 愀氀爀攀愀搀礀 洀攀渀琀椀漀渀攀搀 ∀戀漀漀琀洀攀渀甀∀㰀戀爀㸀ഀഀ is very easy to use, and here you can also specify to which OS the system should autoboot.
਍㰀戀爀㸀ഀഀ Example 2: EFI and RedHat (RHELS 6):
਍㰀戀爀㸀ഀഀ Not using EFI, RedHat boots using the "grub" bootloader, which enters various "stages", and it will also
਍甀猀攀 琀栀攀 ∀⼀戀漀漀琀⼀最爀甀戀⼀最爀甀戀⸀挀漀渀昀∀ 昀椀氀攀 眀栀椀挀栀 栀攀氀瀀猀 琀漀 搀椀猀瀀氀愀礀 愀 戀漀漀琀洀攀渀甀Ⰰ 昀爀漀洀 眀栀椀挀栀 ⠀甀猀甀愀氀氀礀⤀ 瘀愀爀椀漀甀猀㰀戀爀㸀ഀഀ kernel versions can be choosen to boot from.
਍㰀戀爀㸀ഀഀ The EFI implementation is a bit like this:
਍吀栀攀 䔀䘀䤀 匀礀猀琀攀洀 瀀愀爀琀椀琀椀漀渀 椀猀 渀漀眀 ∀⼀戀漀漀琀⼀攀昀椀⼀∀ 漀昀 琀礀瀀攀 瘀䘀䄀吀Ⰰ 眀栀攀爀攀 椀渀 猀甀戀搀椀爀攀挀琀漀爀椀攀猀 琀栀攀 伀匀 氀漀愀搀攀爀猀 漀昀 瘀愀爀椀漀甀猀㰀戀爀㸀ഀഀ Operating systems may reside. For booting to RedHat, the OS Loader directory is "/boot/efi/EFI/redhat/".
਍吀栀椀猀 搀椀爀攀挀琀漀爀礀 挀漀渀琀愀椀渀猀 ∀最爀甀戀⸀攀昀椀∀Ⰰ 眀栀椀挀栀 椀猀 愀 猀瀀攀挀椀愀氀 䜀刀唀䈀 挀漀洀瀀椀氀攀搀 昀漀爀 琀栀攀 䔀䘀䤀 昀椀爀洀眀愀爀攀 愀爀挀栀椀琀攀挀琀甀爀攀⸀㰀戀爀㸀ഀഀ If "autoboot" specifies this loader, then the system will boot to RedHat.
਍㰀戀爀㸀ഀഀ This example is quite similar to example 1, but there are some minor differences per Manufacturer.
਍㰀戀爀㸀ഀഀ This section was indeed a very lightweight discussion on the UEFI implementation. But it will help us later on.
਍一漀琀攀 琀栀愀琀 䤀 猀欀椀瀀瀀攀搀 琀栀攀 䜀倀吀 椀洀瀀氀攀洀攀渀琀愀琀椀漀渀 ⠀爀攀瀀氀愀挀攀洀攀渀琀 漀昀 䴀䈀刀⤀ 栀攀爀攀⸀ 䤀 琀栀椀渀欀 椀琀✀猀 戀攀琀琀攀爀 琀漀 搀漀渀✀琀 搀漀㰀戀爀㸀 ഀഀ "everything in one Bang" so I leave GPT for Chapter 3.
਍㰀戀爀㸀ഀഀ
਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀爀攀搀∀㸀ഀഀ ਍㰀栀㌀㸀 ㈀⸀㐀 伀琀栀攀爀 昀椀爀洀眀愀爀攀ⴀ氀椀欀攀 猀漀氀甀琀椀漀渀猀⸀㰀⼀栀㌀㸀ഀഀ ਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ ਍䄀猀 眀攀 栀愀瘀攀 猀攀攀渀Ⰰ 椀渀 洀愀渀礀 猀礀猀琀攀洀猀Ⰰ 琀栀攀 䬀攀爀渀攀氀 椀猀 ∀栀攀氀瀀攀搀∀ 戀礀 挀漀渀昀椀最甀爀椀渀最 琀栀攀 猀礀猀琀攀洀Ⰰ 甀猀椀渀最 愀 䐀攀瘀椀挀攀 吀爀攀攀⸀㰀戀爀㸀ഀഀ This might be the case in Open Firmware, UEFI systems, and a few others.
਍㰀戀爀㸀ഀഀ However, traditionally other methods are in use as well. There are so many architectures, that it is
਍渀漀琀 爀攀愀氀氀礀 栀攀氀瀀昀甀氀氀 琀漀 挀爀攀愀琀攀 愀氀氀 猀漀爀琀猀 漀昀 氀椀猀琀椀渀最猀 椀渀 琀栀椀猀 渀漀琀攀⸀ 䘀漀爀 攀砀愀洀瀀氀攀Ⰰ 昀漀爀 猀漀洀攀 愀爀挀栀椀琀攀挀琀甀爀攀猀Ⰰ㰀戀爀㸀ഀഀ just a pre-stored file or blob is passed to the kernel when it boots.
਍㰀戀爀㸀ഀഀ But ofcourse Operating Systems themselves can scan buses and find devices. For example, "ioscan" or
਍∀挀昀最洀最爀∀ ⠀昀漀爀 猀漀洀攀 唀渀椀砀 猀礀猀琀攀洀猀⤀ 愀爀攀 愀 昀攀眀 攀砀愀洀瀀氀攀猀 漀昀 挀漀洀洀愀渀搀猀 眀栀椀挀栀 琀栀攀 猀礀猀愀搀洀椀渀 挀愀渀 甀猀攀 琀漀 猀挀愀渀㰀戀爀㸀ഀഀ for new devices, which usually are new local disks or new LUNs from a SAN.
਍匀漀洀攀 渀漀琀攀猀 愀戀漀甀琀 琀栀愀琀 挀愀渀 戀攀 昀漀甀渀搀 椀渀 挀栀愀瀀琀攀爀 㘀⸀㰀戀爀㸀ഀഀ ਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
਍㰀戀爀㸀ഀഀ
਍ഀഀ ਍㰀栀爀⼀㸀ഀഀ

Chapter 3. MBR & GPT.

਍㰀栀爀⼀㸀ഀഀ ਍ഀഀ Sections 3.1 (MBR) and 3.2 (GPT), are about "disk boot structures" on Intel architectures,
਍琀栀愀琀 愀爀攀 甀猀攀搀 戀礀 琀礀瀀椀挀愀氀 伀匀✀猀攀猀 漀渀 琀栀愀琀 瀀氀愀琀昀漀爀洀Ⰰ 氀椀欀攀 䰀椀渀甀砀Ⰰ 嘀䴀圀愀爀攀Ⰰ 圀椀渀搀漀眀猀 愀渀搀 漀琀栀攀爀猀⸀㰀戀爀㸀ഀഀ ਍㰀戀爀㸀ഀഀ ਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀爀攀搀∀㸀ഀഀ ਍㰀栀㌀㸀 ㌀⸀㄀  吀栀攀 䴀䈀刀⸀㰀⼀栀㌀㸀ഀഀ ਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ ਍䤀渀 䌀栀愀瀀琀攀爀 ㈀Ⰰ 眀攀 搀椀猀挀甀猀猀攀猀 ⠀氀椀最栀琀氀礀⤀ 琀栀攀 昀甀渀挀琀椀漀渀 漀昀 唀䔀䘀䤀⸀ 䈀甀琀 瀀愀爀琀 漀昀 唀䔀䘀䤀Ⰰ 椀猀 愀 渀攀眀 戀漀漀琀 猀攀挀琀漀爀 猀琀爀甀挀琀甀爀攀Ⰰ㰀戀爀㸀ഀഀ called "GPT" as a follow up of the traditional MBR.
਍圀攀 搀椀搀 渀漀琀 搀椀猀挀甀猀猀攀猀 䜀倀吀 琀栀攀爀攀Ⰰ 戀攀挀愀甀猀攀 椀琀 洀漀爀攀 漀爀 氀攀猀猀 昀漀挀甀猀攀搀 漀渀 昀椀爀洀眀愀爀攀 愀渀搀 䐀攀瘀椀挀攀 吀爀攀攀猀⸀㰀戀爀㸀ഀഀ Now, it is also time to discuss stuff like MBR and GPT.
਍㰀戀爀㸀ഀഀ For PC systems (workstations & Servers), using BIOS, we can discuss the MBR first, and it's role in booting the system,
਍愀猀 眀攀氀氀 愀猀 椀琀✀猀 氀椀洀椀琀愀琀椀漀渀猀⸀ 䴀椀渀搀 礀漀甀㨀 琀栀攀爀攀 愀爀攀 猀琀椀氀氀 挀漀甀渀琀氀攀猀猀 圀椀渀搀漀眀猀Ⰰ 䰀椀渀甀砀 愀渀搀 漀琀栀攀爀 匀攀爀瘀攀爀⼀圀漀爀欀猀琀愀琀椀漀渀猀㰀戀爀㸀ഀഀ out there, using BIOS, instead of Open Firmware or UEFI.
਍㰀戀爀㸀ഀഀ So here are a few words on MBR...
਍㰀戀爀㸀ഀഀ ਍䤀渀 瘀攀爀礀 愀渀挀椀攀渀琀 琀椀洀攀猀Ⰰ 䌀礀氀椀渀搀攀爀ⴀ䠀攀愀搀ⴀ匀攀挀琀漀爀 ⠀䌀䠀匀⤀ 愀搀搀爀攀猀猀椀渀最 眀愀猀 甀猀攀搀 琀漀 愀搀搀爀攀猀猀 猀攀挀琀漀爀猀 漀昀 愀 搀椀猀欀Ⰰ 戀甀琀 椀猀 眀愀猀㰀戀爀㸀ഀഀ rather quickly replaced by "Logical Block Addressing" (LBA), which uses a simple numbering scheme (0,1,2 etc..) of disksectors.
਍吀栀椀猀 挀漀甀氀搀 椀渀搀攀攀搀 戀攀 椀洀瀀氀攀洀攀渀琀攀搀 椀渀 琀栀漀猀攀 搀愀礀猀Ⰰ 琀栀愀渀欀猀 琀漀 渀攀眀攀爀 氀漀最椀挀 漀渀 琀栀攀 搀椀猀欀挀漀渀琀爀漀氀氀攀爀Ⰰ 愀渀搀 琀栀攀 猀甀瀀瀀漀爀琀 漀昀㰀戀爀㸀ഀഀ BIOS int 13 and Enhanced BIOS implementations.
਍㰀戀爀㸀ഀഀ In this scheme, we simply have one "linear address space", from LBA 0 to LBA N, and leave the details to the
਍漀渀戀漀愀爀搀 氀漀最椀挀 漀昀 琀栀攀 䌀漀渀琀爀漀氀氀攀爀⸀㰀戀爀㸀ഀഀ
਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀爀漀眀渀∀㸀ഀഀ ਍一漀琀攀㨀 琀栀攀爀攀 椀猀 愀渀 椀渀琀攀爀攀猀琀椀渀最 栀椀猀琀漀爀礀 椀渀 ∀最攀漀洀攀琀爀礀 琀爀愀渀猀氀愀琀椀漀渀∀ 洀攀琀栀漀搀猀Ⰰ 愀渀搀 瘀愀爀椀漀甀猀 愀搀搀爀攀猀猀椀渀最 氀椀洀椀琀猀 漀昀 䈀䤀伀匀Ⰰ㰀戀爀㸀 ഀഀ which explains why various partition size limits existed in the past, like the infamous 512M, 2G, 8G, 137G limits.
਍䠀漀眀攀瘀攀爀Ⰰ 琀栀愀琀✀猀 洀甀挀栀 琀漀漀 ∀氀攀渀最琀栀礀∀ 猀漀 䤀 猀欀椀瀀 琀栀愀琀 栀攀爀攀 ⠀椀琀✀猀 愀氀猀漀 渀漀琀 瘀攀爀礀 爀攀氀攀瘀愀渀琀⤀⸀㰀戀爀㸀ഀഀ ਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ ਍㰀戀爀㸀ഀഀ Now there are (or were) at least 2 problems:
਍㰀戀爀㸀ഀഀ (1). Disk manufacturers already have (or want) to go from a fundamental sector size of 512 bytes to 4096 bytes.
਍㰀戀爀㸀ഀഀ (2). The Traditional MBR (Master Boot Record) of a disk is 512 bytes in size. The MBR is located in Sector 0.
਍㰀戀爀㸀ഀഀ The bootsequence of an OS through the MBR is most easiest described using Windows. Not that it's very different
਍昀爀漀洀 愀渀漀琀栀攀爀 漀昀琀攀渀 甀猀攀搀 伀匀 漀渀 䤀渀琀攀氀Ⰰ 氀椀欀攀 䰀椀渀甀砀Ⰰ 戀甀琀 愀 搀攀猀挀爀椀瀀琀椀漀渀 漀昀 愀 䴀䈀刀 戀愀猀攀搀 䰀椀渀甀砀 戀漀漀琀 瘀椀愀 愀 猀琀愀最攀 ㄀ ∀最爀甀戀∀㰀戀爀㸀ഀഀ installed in the MBR, It think, is not very "opportunistic" at this point, so I will just discuss an MBR based Windows boot.
਍㰀戀爀㸀ഀഀ ਍吀栀攀 䴀䈀刀 猀琀愀爀琀猀 眀椀琀栀 椀渀椀琀椀愀氀 戀漀漀琀挀漀搀攀Ⰰ 愀渀搀 猀漀洀攀 琀椀渀礀 攀爀爀漀爀洀攀猀猀愀最攀猀 ⠀氀椀欀攀 ✀䴀椀猀猀椀渀最 伀瀀攀爀愀琀椀渀最 匀礀猀琀攀洀✀⤀ 愀渀搀 琀栀椀猀 戀漀漀琀挀漀搀攀㰀戀爀㸀ഀഀ has a length of 446 bytes. It's followed by the 64 byte "Partition Table", which supports 4 "partition entries" of each 16 bytes.
਍㰀戀爀㸀ഀഀ One partition could be marked "active", and this then was a bootable partition containing the Windows OS bootloader.
਍匀漀Ⰰ 琀栀攀 戀漀漀琀椀渀最 猀攀焀甀攀渀挀攀 椀渀 琀栀攀 䴀䈀刀 猀挀栀攀洀攀Ⰰ 眀愀猀 氀椀欀攀 琀栀椀猀㨀ഀഀ

਍㰀氀椀㸀吀栀攀 椀渀椀琀椀愀氀 戀漀漀琀挀漀搀攀 漀昀 琀栀攀 䴀䈀刀 最攀琀猀 氀漀愀搀攀搀Ⰰ 愀渀搀 爀攀愀搀猀 琀栀攀 瀀愀爀琀椀琀椀漀渀 琀愀戀氀攀⸀㰀⼀氀椀㸀ഀഀ
• The active partition was found, and execution was transferred to the OS loader in that partition (like NTLDR).
਍㰀氀椀㸀吀栀椀猀 伀匀 氀漀愀搀攀爀 琀栀攀渀 椀渀椀琀椀愀琀攀猀 琀栀攀 戀漀漀琀 漀昀 圀椀渀搀漀眀猀⸀㰀戀爀㸀ഀഀ

਍䄀 瘀攀爀礀 猀挀栀攀洀愀琀椀挀 ∀氀愀礀漀甀琀∀ 漀昀 愀渀 䴀䈀刀 氀漀漀欀猀 氀椀欀攀 琀栀椀猀㨀㰀戀爀㸀ഀഀ
਍㰀䈀㸀䘀椀最⸀㐀㨀 匀挀栀攀洀愀 漀昀 琀栀攀 䴀䈀刀⸀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
਍㰀吀䄀䈀䰀䔀 戀漀爀搀攀爀㴀㄀ 䈀䜀䌀伀䰀伀刀㴀⌀㠀㄀䐀䄀䘀㔀㸀ഀഀ ਍㰀吀刀㸀ഀഀ -From starting byte 0 to byte 445 (incl)
਍     ⴀ氀攀渀最琀栀㨀㐀㐀㘀 戀礀琀攀猀㰀⼀䈀㸀㨀㰀戀爀㸀ഀഀ Purpose: Initial bootcode (also for loading/reading
਍     琀栀攀 瀀愀爀琀椀琀椀漀渀 琀愀戀氀攀⤀㰀戀爀㸀ഀഀ and some error messages ਍㰀⼀吀刀㸀ഀഀ ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀㰀䈀㸀ⴀ䘀爀漀洀 猀琀愀爀琀椀渀最 戀礀琀攀 㐀㐀㘀 琀漀 戀礀琀攀 㔀　㤀 ⠀椀渀挀氀⤀㰀戀爀㸀ഀഀ -length: 64 bytes:
਍     倀甀爀瀀漀猀攀㨀 倀愀爀琀椀琀椀漀渀 吀愀戀氀攀㰀戀爀㸀ഀഀ 4 Partition Entries each 16 bytes in length ਍㰀⼀吀刀㸀ഀഀ ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀㰀䈀㸀戀礀琀攀猀 㔀㄀　 愀渀搀 㔀㄀㄀ ⠀㈀ 戀礀琀攀猀⤀㰀⼀䈀㸀㨀㰀戀爀㸀ഀഀ Purpose: 2 byte closing "Boot record signature"
਍     眀椀琀栀 瘀愀氀甀攀猀㨀 㔀㔀 䄀䄀㰀⼀昀漀渀琀㸀㰀⼀吀䐀㸀ഀഀ ਍㰀⼀吀䄀䈀䰀䔀㸀ഀഀ
਍伀渀攀 瀀爀漀戀氀攀洀 眀椀氀氀 最攀琀 挀氀攀愀爀 椀渀 愀 洀漀洀攀渀琀⸀ 䄀 ㄀㘀 戀礀琀攀 倀愀爀琀椀琀椀漀渀 䔀渀琀爀礀 栀愀猀 琀栀攀 昀漀氀氀漀眀椀渀最 猀琀爀甀挀琀甀爀攀㨀㰀戀爀㸀ഀഀ
਍㰀䈀㸀䘀椀最⸀㔀㨀 匀挀栀攀洀愀 漀昀 愀 倀愀爀琀椀琀椀漀渀 䔀渀琀爀礀 椀渀 琀栀攀 䴀䈀刀⸀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
਍㰀吀䄀䈀䰀䔀 戀漀爀搀攀爀㴀㄀ 䈀䜀䌀伀䰀伀刀㴀⌀㠀㄀䐀䄀䘀㔀㸀ഀഀ ਍㰀吀刀㸀ഀഀ Lengt (bytes): ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀䌀漀渀琀攀渀琀㨀㰀⼀吀䐀㸀ഀഀ ਍㰀吀刀㸀ഀഀ 1 ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀䈀漀漀琀 䤀渀搀椀挀愀琀漀爀 ⠀㠀　栀㴀愀挀琀椀瘀攀⤀㨀㰀⼀吀䐀㸀ഀഀ ਍㰀吀刀㸀ഀഀ 3 ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀匀琀愀爀琀椀渀最 䌀匀䠀㰀⼀吀䐀㸀ഀഀ ਍㰀吀刀㸀ഀഀ 1 ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀倀愀爀琀椀琀椀漀渀 吀礀瀀攀 䐀攀猀挀爀椀瀀琀漀爀㰀⼀吀䐀㸀ഀഀ ਍㰀吀刀㸀ഀഀ 3 ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀䔀渀搀椀渀最 䌀匀䠀㰀⼀吀䐀㸀ഀഀ ਍㰀吀刀㸀ഀഀ ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀㐀㰀⼀吀䐀㸀ഀഀ Starting Sector ਍㰀⼀吀刀㸀ഀഀ ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀㐀㰀⼀吀䐀㸀ഀഀ Partition size (Sectors) ਍㰀⼀吀刀㸀ഀഀ ਍㰀⼀吀䄀䈀䰀䔀㸀 ഀഀ ਍㰀戀爀㸀ഀഀ The last 2 fields express the problem. For example, the "partition size" (in no of sectors), is 4 bytes (32 bits) long, so it
਍挀愀渀 栀愀瘀攀 愀猀 愀 洀愀砀椀洀甀洀 瘀愀氀甀攀 ∀䘀䘀 䘀䘀 䘀䘀 䘀䘀∀ 椀渀 栀攀砀Ⰰ 眀栀椀挀栀 椀猀 ∀㐀㈀㤀㐀㤀㘀㜀㈀㤀㔀∀ 椀渀 搀攀挀椀洀愀氀⸀ 匀漀Ⰰ 眀栀攀渀 甀猀椀渀最 㔀㄀㈀戀礀琀攀 猀攀挀琀漀爀猀椀稀攀Ⰰ㰀戀爀㸀ഀഀ this amounts to about 4294967295 x 512=2.199.023.255.040 bytes, or a maximum partition size of 2.2 TB.
਍㰀戀爀㸀ഀഀ The fact that only 4 partitions (not counting optional logigal drives in an "extended" partition)
਍愀爀攀 瀀漀猀猀椀戀氀攀Ⰰ 愀渀搀 琀栀椀猀 瀀愀爀琀椀琀椀漀渀 猀椀稀攀 氀椀洀椀琀Ⰰ 琀栀攀猀攀 氀椀洀椀琀猀 愀爀攀Ⰰ 昀漀爀 琀漀搀愀礀✀猀 猀琀愀渀搀愀爀搀猀Ⰰ 挀漀渀猀椀搀攀爀攀搀 琀漀 戀攀 琀漀漀 猀洀愀氀氀⸀㰀戀爀㸀ഀഀ
਍匀漀Ⰰ 愀猀 礀漀甀 挀愀渀 爀攀愀搀 椀渀 愀 琀爀椀氀氀椀漀渀 漀琀栀攀爀 椀渀琀攀爀渀攀琀 搀漀挀甀洀攀渀琀猀Ⰰ 琀栀攀 䜀唀䤀䐀 倀愀爀琀椀琀椀漀渀 吀愀戀氀攀Ⰰ 漀爀 䜀倀吀Ⰰ 椀猀 琀栀攀 爀攀瀀氀愀挀攀洀攀渀琀㰀戀爀㸀ഀഀ for the MBR.
਍㰀戀爀㸀ഀഀ As we have seen in Chapter 2, UEFI is a new firmware interface for newer Intel machines, as a replacement
਍昀漀爀 琀栀攀 琀爀愀搀椀琀椀漀渀愀氀 䈀䤀伀匀⸀㰀戀爀㸀ഀഀ
਍䄀氀猀漀Ⰰ 琀栀攀 唀䔀䘀䤀 猀瀀攀挀椀昀椀挀愀琀椀漀渀猀 猀甀瀀瀀漀猀攀猀 琀栀愀琀 琀栀攀 洀愀挀栀椀渀攀 最攀琀猀 愀 ∀䔀䘀䤀 匀礀猀琀攀洀 倀愀爀琀椀琀椀漀渀∀⸀ 匀漀⸀⸀ 眀栀愀琀 椀猀 琀栀攀 爀攀氀愀琀椀漀渀㰀戀爀㸀ഀഀ with GPT, which is also a UEFI spec?
਍䤀琀 猀攀攀洀猀 挀漀洀瀀氀椀挀愀琀攀搀Ⰰ 㰀䤀㸀戀甀琀 椀琀猀 爀攀愀氀氀礀 渀漀琀 ℀㰀⼀䤀㸀㰀戀爀㸀ഀഀ
਍䄀猀 椀琀 琀甀爀渀猀 漀甀琀Ⰰ 椀昀 礀漀甀 栀愀瘀攀 愀 唀䔀䘀䤀 挀漀洀瀀氀椀愀渀琀 洀愀挀栀椀渀攀Ⰰ 愀渀搀 礀漀甀 椀渀猀琀愀氀氀 愀 唀䔀䘀䤀 挀漀洀瀀氀椀愀渀琀 伀匀Ⰰ㰀戀爀㸀ഀഀ then you get GPT with a "EFI System Partition".
਍㰀戀爀㸀ഀഀ What makes it all a bit cloudy, is that a GPT disk, is actually sort of "self describing" which has as a
਍挀漀渀猀攀焀甀攀渀挀攀 琀栀愀琀 礀漀甀 挀愀渀 甀猀攀 愀 䜀倀吀 搀椀猀欀 攀瘀攀渀 眀椀琀栀 愀 䈀䤀伀匀 戀愀猀攀搀 猀礀猀琀攀洀Ⰰ 愀氀琀栀漀甀最栀 眀椀琀栀 挀攀爀琀愀椀渀 爀攀猀琀爀椀挀琀椀漀渀猀⸀㰀戀爀㸀ഀഀ
਍㰀䈀㸀匀漀Ⰰ 唀䔀䘀䤀 椀猀 愀挀琀甀愀氀氀礀 渀漀琀 爀攀焀甀椀爀攀搀 昀漀爀 甀猀椀渀最 愀 䜀倀吀 搀椀猀欀⸀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
਍吀栀椀猀 眀椀氀氀 戀攀 攀砀瀀氀愀椀渀攀搀 戀攀琀琀攀爀 椀渀 琀栀攀 渀攀砀琀 猀攀挀琀椀漀渀⸀㰀戀爀㸀ഀഀ
਍䤀渀搀攀攀搀Ⰰ 瀀漀瀀甀氀愀爀 伀匀✀猀攀猀 漀渀 䤀渀琀攀氀 氀椀欀攀 㰀䈀㸀嘀䴀圀愀爀攀Ⰰ 䰀椀渀甀砀 搀椀猀琀爀漀猀Ⰰ 圀椀渀搀漀眀猀㰀⼀䈀㸀Ⰰ 琀栀攀礀 愀氀氀 甀猀攀搀 䴀䈀刀 椀渀 琀栀攀 瀀愀猀琀Ⰰ㰀戀爀㸀ഀഀ but later versions are switched to GPT.
਍㰀戀爀㸀ഀഀ Later on, you will find a table listing those OS'ses, with respect to Version, 32/64 bit, UEFI/BIOS system,
਍愀渀搀 猀栀漀眀椀渀最 椀昀 琀栀攀礀 挀愀渀 甀猀攀 䜀倀吀⸀㰀戀爀㸀ഀഀ
਍㰀戀爀㸀ഀഀ ਍ഀഀ

3.2 The GUID Partition Table (GPT).

਍ഀഀ ਍ഀഀ The GUID Partition Table is the follow up of the MBR. In section 3.1, we have seen how the MBR was structured,
਍栀漀眀 椀琀 眀愀猀 甀猀攀搀 椀渀 琀栀攀 戀漀漀琀猀攀焀甀攀渀挀攀Ⰰ 愀渀搀 琀栀攀 氀椀洀椀琀愀琀椀漀渀猀 瀀漀猀攀搀 戀礀 琀栀攀 䴀䈀刀 愀渀搀 倀愀爀琀椀琀椀漀渀 䔀渀琀爀椀攀猀⸀㰀戀爀㸀ഀഀ
਍䌀漀渀琀爀愀爀礀 琀漀 琀栀攀 猀椀洀瀀氀攀 愀渀搀 猀洀愀氀氀 䴀䈀刀 ⠀漀昀 㔀㄀㈀ 戀礀琀攀猀 氀漀渀最⤀Ⰰ 琀栀攀 䜀倀吀 椀猀 愀 挀漀洀瀀氀攀琀攀氀礀 搀椀昀昀攀爀攀渀琀 琀栀椀渀最⸀㰀戀爀㸀ഀഀ
਍䄀猀 猀愀椀搀 戀攀昀漀爀攀Ⰰ 䜀倀吀 椀猀 瀀愀爀琀 漀昀 琀栀攀 唀䔀䘀䤀 猀瀀攀挀椀昀椀挀愀琀椀漀渀猀⸀ 䤀渀 瀀爀愀挀琀椀挀攀Ⰰ 琀栀攀 昀漀氀氀漀眀椀渀最 猀琀愀琀攀洀攀渀琀猀 愀爀攀 琀爀甀攀㨀㰀戀爀㸀ഀഀ

਍㰀氀椀㸀䄀渀 猀礀猀琀攀洀 眀椀琀栀 唀䔀䘀䤀 昀椀爀洀眀愀爀攀Ⰰ 眀椀氀氀 渀愀琀椀瘀攀氀礀 甀猀攀 䜀倀吀 戀愀猀攀搀 搀椀猀欀猀Ⰰ 愀渀搀 挀愀渀 戀漀漀琀 昀爀漀洀 愀 䜀倀吀 搀椀猀欀⸀㰀⼀氀椀㸀ഀഀ
• An (older) BIOS based system, can use GPT based disks as data disks, but cannot boot from a GPT disk.
਍㰀氀椀㸀匀漀Ⰰ 唀䔀䘀䤀 椀猀 渀漀琀 ∀瀀攀爀猀攀∀ 爀攀焀甀椀爀攀搀 昀漀爀 甀猀椀渀最 䜀倀吀 搀椀猀欀猀㰀⼀氀椀㸀ഀഀ
• Most newer releases of popular (Intel based) OS'ses, transfer to using UEFI and GPT disks (or already UEFI based).
਍㰀氀椀㸀䄀 䜀倀吀 戀愀猀攀搀 搀椀猀欀 甀猀攀猀 愀猀 琀栀攀 昀椀爀猀琀 猀攀挀琀漀爀 ⠀䰀䈀䄀 　⤀ 愀 䴀䈀刀 氀椀欀攀 猀琀爀甀挀琀甀爀攀Ⰰ 挀愀氀氀攀搀 㰀䈀㸀∀琀栀攀 瀀爀漀琀攀挀琀椀瘀攀 䴀䈀刀∀㰀⼀䈀㸀Ⰰ㰀戀爀㸀ഀഀ which precedes the newer GPT implementation. It looks exactly the same a the oldfashioned MBR, but it was added
਍昀漀爀 猀攀瘀攀爀愀氀 爀攀愀猀漀渀猀Ⰰ 氀椀欀攀 瀀爀漀琀攀挀琀椀漀渀 昀爀漀洀 漀氀搀攀爀 琀漀漀氀猀 氀椀欀攀 ∀昀搀椀猀欀∀ 漀爀 氀攀最愀挀礀 瀀爀漀最爀愀洀猀 愀渀搀 甀琀椀氀椀琀椀攀猀⸀㰀⼀氀椀㸀ഀഀ

਍㰀戀爀㸀ഀഀ A GPT is way larger than the old MBR. A GPT spans multiple LBA's. In fact, GPT reserves LBA 0 to LBA 33,
਍氀攀愀瘀椀渀最 䰀䈀䄀 ㌀㐀 椀猀 琀栀攀 昀椀爀猀琀 甀猀愀戀氀攀 猀攀挀琀漀爀 昀漀爀 愀 琀爀甀攀 倀愀爀琀椀琀椀漀渀⸀㰀戀爀㸀ഀഀ So, as from LBA 34, we can have a number of true partitions, that is, usable diskspace like C:, D: etc..
਍㰀戀爀㸀ഀഀ But the "end" of the disk is special again! It's a copy of the GPT, which can be used for recovery purposes.
਍㰀戀爀㸀ഀഀ Just as we did in figure 4 for the MBR, let's take a look at a schematic representation of the GPT.
਍匀椀渀挀攀 眀攀 挀愀渀 渀甀洀戀攀爀 猀攀挀琀漀爀猀 樀甀猀琀 戀礀 爀攀昀攀爀椀渀最 琀漀 䰀䈀䄀 渀甀洀戀攀爀猀Ⰰ 氀攀琀✀猀 甀猀攀 琀栀愀琀 愀猀 眀攀氀氀⸀ 匀漀Ⰰ 椀昀 眀攀 甀猀攀 琀栀愀琀㰀戀爀㸀ഀഀ for example in the old MBR scheme, it that case we can then say that the MBR was in "LBA 0".
਍ഀഀ
਍㰀䈀㸀䘀椀最⸀㘀㨀 匀椀洀瀀氀椀昀椀攀搀 匀挀栀攀洀愀 漀昀 琀栀攀 䜀唀䤀䐀 倀愀爀琀椀琀椀漀渀 吀愀戀氀攀⸀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
਍㰀吀䄀䈀䰀䔀 戀漀爀搀攀爀㴀㄀ 䈀䜀䌀伀䰀伀刀㴀⌀㠀㄀䐀䄀䘀㔀㸀ഀഀ ਍㰀吀刀㸀ഀഀ LBA 0 ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀倀爀漀琀攀挀琀椀瘀攀 䴀䈀刀㰀⼀吀䐀㸀ഀഀ ਍㰀吀刀㸀ഀഀ LBA 1 ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀倀爀椀洀愀爀礀 䜀倀吀 䠀攀愀搀攀爀㰀⼀吀䐀㸀ഀഀ ਍㰀吀刀㸀ഀഀ LBA 2 ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀倀愀爀琀椀琀椀漀渀 吀愀戀氀攀 猀琀愀爀琀猀⸀㰀戀爀㸀ഀഀ Partition Entries 1,2,3,4 ਍㰀⼀吀刀㸀ഀഀ ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀䰀䈀䄀 ㌀ ⴀ ㌀㌀㰀⼀吀䐀㸀ഀഀ Partition Entries 5-128 ਍㰀⼀吀刀㸀ഀഀ ਍㰀吀䄀䈀䰀䔀 戀漀爀搀攀爀㴀㄀ 䈀䜀䌀伀䰀伀刀㴀⌀䘀䔀㤀䄀㈀䔀㸀ഀഀ ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀䰀䈀䄀 ㌀㐀 ⴀ䰀䈀䄀 䴀㰀⼀吀䐀㸀ഀഀ Possible first true Partition (like C:) ਍㰀⼀吀刀㸀ഀഀ ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀䰀䈀䄀 䴀⬀㄀ ⴀ 䰀䈀䄀 一 㰀⼀吀䐀㸀ഀഀ Possible Second true Partition (like D:) ਍㰀⼀吀刀㸀ഀഀ ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀伀琀栀攀爀 䰀䈀䄀✀猀Ⰰ 攀砀挀攀瀀琀 琀栀攀 氀愀猀琀 ㌀㌀ 䰀䈀䄀✀猀㰀⼀吀䐀㸀ഀഀ Possible other partitions
਍                                 甀瀀 琀漀 琀栀攀 氀愀猀琀 䰀䈀䄀㨀 䔀一䐀开伀䘀开䐀䤀匀䬀 ⴀ㌀㐀㰀⼀吀䐀㸀ഀഀ ਍㰀⼀吀䄀䈀䰀䔀㸀ഀഀ ਍㰀吀刀㸀ഀഀ ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀倀愀爀琀椀琀椀漀渀 䔀渀琀爀椀攀猀 ㄀Ⰰ㈀Ⰰ㌀Ⰰ㐀 ⠀挀漀瀀礀⤀㰀⼀吀䐀㸀ഀഀ ਍㰀吀刀㸀ഀഀ ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀倀愀爀琀椀琀椀漀渀 䔀渀琀爀椀攀猀 㔀ⴀ㄀㈀㠀 ⠀挀漀瀀礀⤀㰀⼀吀䐀㸀ഀഀ ਍㰀吀刀㸀ഀഀ ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀匀攀挀漀渀搀愀爀礀 䜀倀吀 䠀攀愀搀攀爀 ⠀挀漀瀀礀⤀㰀⼀吀䐀㸀ഀഀ ਍ഀഀ

END_OF_DISK - 33

END_OF_DISK - 32

END_OF_DISK - 1

਍㰀戀爀㸀ഀഀ Please be aware that the LBA numbers (like the starting "LBA 34" for usable partitions), is not exactly
਍猀瀀攀挀椀昀椀攀搀 椀渀 琀栀攀 漀爀椀最椀渀愀氀 猀瀀攀挀椀昀椀挀愀琀椀漀渀猀⸀㰀戀爀㸀ഀഀ If you take the numbers like in the above table, like 128 byte sized Partition Entries, and "room"
਍昀漀爀 㔀 甀瀀 琀漀 ㄀㈀㠀 倀愀爀琀椀琀椀漀渀 䔀渀琀爀椀攀猀Ⰰ 漀渀氀礀 琀栀攀渀 礀漀甀 眀椀氀氀 攀渀搀 甀瀀 椀渀 䰀䈀䄀 ㌀㐀 愀猀 愀 猀琀愀爀琀瀀漀椀渀琀 昀漀爀 甀猀愀戀氀攀 搀愀琀愀⸀㰀戀爀㸀ഀഀ
਍ഀഀ In GPT, in a Partition Entry, the "partition size field" (in no of sectors/LBA's), is now 64 bits wide.
਍吀栀椀猀 愀洀漀甀渀琀猀 琀漀 愀 洀愀砀 瀀愀爀琀椀琀椀漀渀 猀椀稀攀 漀昀 愀戀漀甀琀 㤀⸀㐀 娀攀琀愀䈀礀琀攀猀 ⠀愀戀漀甀琀 㤀⸀㐀 戀椀氀氀椀漀渀 吀攀爀愀 䈀礀琀攀猀⤀Ⰰ 眀栀椀挀栀 椀猀 焀甀椀琀攀 氀愀爀最攀 椀渀搀攀攀搀⸀㰀戀爀㸀ഀഀ You can easily do that math yourself (if needed, take a look at the math in section 3.1).
਍㰀戀爀㸀ഀഀ Note that the information in a GPT, or even MBR, can be considered to form "metadata" of a disk,
਍猀椀渀挀攀 戀漀琀栀 搀攀猀挀爀椀戀攀猀 琀栀攀 猀琀爀甀挀琀甀爀攀 漀昀 琀栀攀 搀椀猀欀 ⠀氀椀欀攀 ∀眀栀攀爀攀∀ 椀猀 ∀眀栀椀挀栀∀ 瀀愀爀琀椀琀椀漀渀 漀渀 ∀眀栀愀琀∀ 氀漀挀愀琀椀漀渀 攀琀挀⸀⸀⤀⸀㰀戀爀㸀ഀഀ
਍刀攀洀攀洀戀攀爀 琀栀攀 唀䔀䘀䤀 匀礀猀琀攀洀 倀愀爀琀椀琀椀漀渀 ⠀䔀匀倀⤀ 愀猀 搀攀猀挀爀椀戀攀搀 椀渀 猀攀挀琀椀漀渀 ㈀⸀㌀㼀㰀戀爀㸀ഀഀ On a "native" UEFI system, it will be automatically created as one partition on the first disk.
਍匀漀Ⰰ 椀琀 眀椀氀氀 甀猀甀愀氀氀礀 戀攀 琀栀攀 昀椀爀猀琀 瀀愀爀琀椀琀椀漀渀 椀渀 琀栀攀 ∀漀爀愀渀最攀 愀爀攀愀∀ 愀猀 搀攀瀀椀挀琀攀搀 椀渀 昀椀最甀爀攀 㘀⸀㰀戀爀㸀ഀഀ Depending on the Manufacturer, it's size may vary somewhat, but it's typically about a few hundreds MB or so,
਍猀椀渀挀攀 椀琀 漀渀氀礀 渀攀攀搀猀 琀漀 猀琀漀爀攀 琀栀攀 甀攀昀椀 洀攀琀愀搀愀琀愀 愀渀搀 伀匀 戀漀漀琀氀漀愀搀攀爀猀 ⠀猀攀攀 愀氀猀漀 昀椀最甀爀攀 ㌀⤀⸀㰀戀爀㸀ഀഀ
਍一漀琀攀㨀㰀戀爀㸀ഀഀ
਍䘀漀爀 伀匀✀猀攀猀 氀椀欀攀 䰀椀渀甀砀Ⰰ 圀椀渀搀漀眀猀Ⰰ 椀琀 猀栀漀甀氀搀 戀攀 猀琀爀攀猀猀攀搀 㰀䈀㸀渀漀琀㰀⼀䈀㸀 琀漀 甀猀攀 漀氀搀攀爀 䜀倀吀 㰀䈀㸀甀渀愀眀愀爀攀㰀⼀䈀㸀 琀漀漀氀猀㰀戀爀㸀ഀഀ like "fdisk" and the like.
਍䘀漀爀 攀砀愀洀瀀氀攀Ⰰ 漀渀 爀攀挀攀渀琀 瘀攀爀猀椀漀渀猀 漀昀 䰀椀渀甀砀Ⰰ 琀栀攀 琀爀愀搀椀琀椀漀渀愀氀 ∀昀搀椀猀欀∀ 琀漀漀氀 椀猀 爀攀瀀氀愀挀攀搀 戀礀 甀琀椀氀椀琀椀攀猀 氀椀欀攀 ∀瀀愀爀琀攀搀∀⸀㰀戀爀㸀ഀഀ
਍㰀戀爀㸀ഀഀ ਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀爀攀搀∀㸀ഀഀ ਍㰀栀㌀㸀 ㌀⸀㌀  匀漀洀攀 昀椀最甀爀攀猀 椀氀氀甀猀琀爀愀琀椀渀最 愀 䈀䤀伀匀⼀䴀䈀刀 戀漀漀琀Ⰰ 愀渀搀 愀渀 唀䔀䘀䤀⼀䜀倀吀 戀漀漀琀⸀㰀⼀栀㌀㸀ഀഀ ਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ ਍㰀栀㐀㸀㌀⸀㌀⸀㄀⸀ 䈀䤀伀匀 愀渀搀 䴀䈀刀㨀㰀⼀栀㐀㸀ഀഀ ਍㰀䈀㸀䘀椀最 㜀⸀ 匀椀洀瀀氀椀昀椀攀搀 攀砀愀洀瀀氀攀 漀昀 愀 䈀䤀伀匀⼀䴀䈀刀 椀渀椀琀椀愀琀攀搀 戀漀漀琀 漀昀 愀渀 ∀漀氀搀攀爀∀ 圀椀渀搀漀眀猀 猀礀猀琀攀洀 氀椀欀攀 圀椀渀㈀䬀㌀⸀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
਍㰀椀洀最 猀爀挀㴀∀搀椀猀欀搀攀瘀椀挀攀猀㐀⸀樀瀀最∀ 愀氀椀最渀㴀∀挀攀渀琀爀攀∀⼀㸀ഀഀ
਍㰀戀爀㸀ഀഀ In fig 7, we see an "old-fashioned style" boot of a once popular OS like XP, Win2K3 etc..
਍圀栀愀琀 眀攀 猀攀攀 栀攀爀攀Ⰰ 椀猀 琀栀攀 猀琀甀昀昀 眀攀 栀愀瘀攀 琀愀氀欀攀搀 愀戀漀甀琀 戀攀昀漀爀攀⸀㰀戀爀㸀ഀഀ
਍ⴀ吀栀攀 䈀䤀伀匀 猀攀氀攀挀琀猀 愀 戀漀漀琀愀戀氀攀 搀攀瘀椀挀攀⸀ 䴀愀礀戀攀 椀琀 琀爀椀攀猀 琀栀攀 䐀嘀䐀 昀椀爀猀琀Ⰰ 戀攀昀漀爀攀 最漀椀渀最 琀漀 栀愀爀搀搀椀猀欀　⸀㰀戀爀㸀ഀഀ -Then, it loads the "initial bootcode" from the MBR, which will access the "partition table".
਍ⴀ吀栀攀渀 椀琀 搀攀琀攀爀洀椀渀攀猀 琀栀攀 猀瀀攀挀猀 昀爀漀洀 琀栀攀 ∀愀挀琀椀瘀攀∀ 漀爀 ∀戀漀漀琀愀戀氀攀 瀀愀爀琀椀琀椀漀渀∀ ⠀昀漀爀 攀砀愀洀瀀氀攀Ⰰ 眀栀攀爀攀 椀琀 猀琀愀爀琀猀⤀⸀㰀戀爀㸀ഀഀ This partition could be, for example, partition No 1.
਍㰀戀爀㸀ഀഀ -Control is then passed to the OS loader on that partition (in this example, "NTLDR").
਍ⴀ一攀砀琀Ⰰ 渀琀氀搀爀 爀攀愀搀猀 ∀戀漀漀琀⸀椀渀椀∀ 眀栀椀挀栀 椀猀 愀 猀洀愀氀氀 昀椀氀攀 挀漀渀琀愀椀渀椀渀最 猀漀挀愀氀氀攀搀 ∀愀爀挀∀ 瀀愀琀栀猀Ⰰ 眀栀椀挀栀 ∀瀀漀椀渀琀猀∀ 琀漀 琀栀攀 瀀愀爀琀椀琀椀漀渀猀㰀戀爀㸀ഀഀ containing Operating Systems.
਍䘀漀爀 攀砀愀洀瀀氀攀Ⰰ 猀甀挀栀 愀渀 愀爀挀 瀀愀琀栀 挀漀甀氀搀 瀀漀椀渀琀 琀漀 瀀愀爀琀椀琀椀漀渀 一漀 ㈀ ⠀漀爀 琀漀 昀漀爀 攀砀愀洀瀀氀攀 瀀愀爀琀椀琀椀漀渀 一漀 ㄀ 漀渀 愀渀漀琀栀攀爀 搀椀猀欀⤀⸀㰀戀爀㸀ഀഀ
਍ⴀ䘀爀漀洀 琀栀攀渀Ⰰ 琀栀攀 戀漀漀琀猀攀焀甀攀渀挀攀 漀昀 琀栀愀琀 伀匀 爀攀愀氀氀礀 猀琀愀爀琀猀⸀㰀戀爀㸀ഀഀ
਍一漀眀 礀漀甀 洀愀礀 猀愀礀㨀 ∀琀栀椀猀 椀猀 圀椀渀搀漀眀猀 ℀∀㰀⼀䤀㸀 匀漀 栀漀眀 愀戀漀甀琀 愀渀漀琀栀攀爀 伀匀 琀栀愀琀 愀氀猀漀 椀渀椀琀椀愀氀氀礀 猀琀愀爀琀猀 昀爀漀洀 䈀䤀伀匀⼀䴀䈀刀Ⰰ 氀椀欀攀 䰀椀渀甀砀 刀䠀䔀䰀 㔀 漀爀 猀漀㼀㰀戀爀㸀ഀഀ Ok, the following figure it not so terribly different from fig 7, but I like to show it here anyway.
਍㰀戀爀㸀ഀഀ Fig 8. Simplified example of a BIOS/MBR initiated boot of an "older" Linux system like RHEL5.
਍㰀戀爀㸀ഀഀ ਍㰀戀爀㸀ഀഀ
਍吀栀椀猀 渀漀琀攀 椀猀 渀漀琀 昀漀爀 搀椀猀挀甀猀猀椀渀最 戀漀漀琀猀攀焀甀攀渀挀攀猀 椀渀 搀攀琀愀椀氀⸀ 䠀漀眀攀瘀攀爀Ⰰ 琀栀攀 漀瘀攀爀愀氀氀 猀攀焀甀攀渀挀攀 漀昀 攀瘀攀渀琀猀 椀猀 瘀椀猀椀戀氀攀 椀渀 昀椀最甀爀攀 㠀⸀㰀戀爀㸀ഀഀ Ofcourse, the start of the Linux OS as such, is depicted to happed as of Step 7 in figure 8.
਍䄀琀 琀栀椀猀 瀀漀椀渀琀Ⰰ 琀栀漀猀攀 瀀栀愀猀攀猀 愀爀攀 渀漀琀 猀漀 漀昀 椀渀琀攀爀攀猀琀Ⰰ 猀漀 琀栀愀琀✀猀 眀栀礀 椀琀 眀愀猀 渀漀琀 搀攀琀愀椀氀攀搀 昀甀爀琀栀攀爀⸀㰀戀爀㸀ഀഀ
਍㰀栀㐀㸀㌀⸀㌀⸀㈀⸀ 唀䔀䘀䤀 甀猀椀渀最 䜀倀吀㨀㰀⼀栀㐀㸀ഀഀ ਍䄀挀琀甀愀氀氀礀Ⰰ 眀攀 愀氀爀攀愀搀礀 栀愀瘀攀 搀椀猀挀甀猀猀攀搀 琀栀攀 唀䔀䘀䤀 戀漀漀琀 椀渀 猀攀挀琀椀漀渀 ㈀⸀㌀⸀ 䠀漀眀攀瘀攀爀Ⰰ 栀攀爀攀 䤀 琀爀礀 琀漀 瀀爀漀搀甀挀攀 愀 昀椀最甀爀攀 琀栀愀琀 椀氀氀甀猀琀爀愀琀攀猀㰀戀爀㸀ഀഀ a bit more on the role of GPT, and the UEFI System Partition.
਍䠀攀爀攀Ⰰ 䤀 眀椀氀氀 漀渀氀礀 猀栀漀眀 琀栀愀琀 瀀椀挀琀甀爀攀⸀ 䤀昀 礀漀甀 渀攀攀搀 洀漀爀攀 椀渀昀漀 漀渀 唀䔀䘀䤀 椀琀猀攀氀昀Ⰰ 礀漀甀 洀椀最栀琀 挀栀攀挀欀 猀攀挀琀椀漀渀 ㈀⸀㌀⸀㰀戀爀㸀ഀഀ So lets give it a try:
਍㰀戀爀㸀ഀഀ Fig 9. Simplified example of a UEFI/GPT initiated boot.
਍㰀戀爀㸀ഀഀ ਍㰀戀爀㸀ഀഀ
਍伀欀Ⰰ 䤀 洀礀猀攀氀昀 眀漀甀氀搀 挀攀爀琀愀椀渀氀礀 渀漀琀 最椀瘀攀 愀渀 ∀䄀 爀愀琀椀渀最∀ 琀漀 琀栀攀 昀椀最甀爀攀 愀戀漀瘀攀Ⰰ 戀甀琀 椀琀 猀栀漀甀氀搀 栀攀氀瀀 ∀猀漀洀攀眀栀愀琀∀ 椀渀 甀渀搀攀爀猀琀愀渀搀椀渀最 唀䔀䘀䤀 戀漀漀琀猀⸀㰀戀爀㸀ഀഀ
਍吀栀攀 昀椀爀洀眀愀爀攀 戀漀漀琀Ⰰ 椀猀 搀攀挀猀挀爀椀戀攀搀 椀渀 猀攀挀琀椀漀渀 ㈀⸀㌀⸀ 䄀琀 愀 挀攀爀琀愀椀渀 洀漀洀攀渀琀Ⰰ 琀栀攀 唀䔀䘀䤀 戀漀漀琀洀愀渀愀最攀爀 爀攀攀搀猀 琀栀攀 䜀倀吀⸀㰀戀爀㸀ഀഀ Since the GPT is "metadata", mainly about true partitions, partitions can be indentified by there Globally Unique Id, the GUID.
਍㰀戀爀㸀ഀഀ So, from the GPT, UEFI tries to indentify the "EUFI System Partition (EPT)", by it's unique GUID,
਍眀栀椀挀栀 猀栀漀甀氀搀 戀攀 氀椀欀攀 䌀㄀㈀䄀㜀㌀㈀㠀ⴀ䘀㠀㄀䘀ⴀ㄀㄀䐀㈀ⴀ䈀䄀㐀䈀ⴀ　　䄀　䌀㤀㌀䔀䌀㤀㌀䈀⸀㰀戀爀㸀ഀഀ
਍伀渀挀攀 昀漀甀渀搀Ⰰ 唀䔀䘀䤀 挀愀渀 氀漀挀愀琀攀 琀栀攀 挀漀爀爀攀挀琀 伀匀 氀漀愀搀攀爀Ⰰ 椀渀 挀愀猀攀 愀甀琀漀戀漀漀琀 椀猀 椀渀 攀昀昀攀挀琀⸀㰀戀爀㸀ഀഀ
਍䌀漀渀琀愀爀礀 琀漀 琀栀攀 ∀渀愀琀椀瘀攀∀ 䴀䈀刀 猀椀琀甀愀琀椀漀渀 愀猀 猀栀漀眀渀 椀渀 猀攀挀琀椀漀渀 ㌀⸀㌀⸀㄀Ⰰ 唀䔀䘀䤀 搀漀攀猀 㰀䈀㸀一伀吀㰀⼀䈀㸀 氀漀愀搀 ∀椀渀椀琀椀愀氀 戀漀漀琀挀漀搀攀∀ 昀爀漀洀 䜀倀吀⸀㰀戀爀㸀ഀഀ So, in this phase, no sort of bootsecor with code, is loaded.
਍伀渀氀礀 洀攀琀愀 搀愀琀愀 椀猀 爀攀愀搀⸀ 吀栀攀 瀀爀攀戀漀漀琀 椀猀 昀甀氀氀礀 挀漀渀琀愀椀渀琀攀搀 椀渀 唀䔀䘀䤀 椀琀猀攀氀昀⸀㰀戀爀㸀ഀഀ
਍ഀഀ

3.3.3. UEFI using MBR:

਍ഀഀ Now, the following might "feel" a bit strange. In the discussion above, we have seen that UEFI more or less
਍攀砀瀀攀挀琀猀 䜀唀䤀䐀 倀愀爀琀椀琀椀漀渀 吀愀戀氀攀 洀攀琀愀搀愀琀愀 ⠀䜀倀吀⤀⸀ 䤀渀搀攀攀搀Ⰰ 䜀倀吀 椀猀 瀀愀爀琀 漀昀 琀栀攀 唀䔀䘀䤀 猀瀀攀挀椀昀椀挀愀琀椀漀渀猀⸀㰀戀爀㸀ഀഀ
਍䠀漀眀攀瘀攀爀Ⰰ 洀愀渀甀昀愀挀琀甀爀攀爀猀 猀漀洀攀琀椀洀攀猀 昀椀渀搀 猀洀愀爀琀 眀愀礀猀 ⠀漀爀 洀愀礀戀攀 渀漀琀 猀漀 猀洀愀爀琀 眀愀礀猀⤀ 琀漀 椀洀瀀氀攀洀攀渀琀 猀漀爀琀 漀昀 栀礀戀爀椀搀 昀漀爀洀猀⸀㰀戀爀㸀ഀഀ Since the "EFI System Partition" (ESP) actually is "just" a partition, like any other partition (only with a special content),
਍椀琀 愀挀琀甀愀氀氀礀 椀猀 瀀漀猀猀椀戀氀攀 琀漀 栀愀瘀攀 愀 猀礀猀琀攀洀 眀椀琀栀 愀渀 䔀匀倀Ⰰ 甀猀椀渀最 琀栀攀 ∀漀氀搀 䴀䈀刀 猀琀礀氀攀∀ 洀攀琀愀搀愀琀愀⸀㰀戀爀㸀ഀഀ In this case, in a Partition Entry in the MBR, the ESP can be indentified by it's ID of value "0xEF".
਍㰀戀爀㸀ഀഀ There actually exists (some might say, "weird") variants. It's possible to replace the original bootcode
਍椀渀 琀栀攀 猀琀愀渀搀愀爀搀 䴀䈀刀Ⰰ 琀漀 愀 瘀愀爀椀愀渀琀 ∀眀栀椀挀栀 氀漀漀欀猀 氀椀欀攀 䔀䘀䤀 昀椀爀洀眀愀爀攀∀⸀ 吀栀椀猀 洀愀欀攀猀 椀琀 攀瘀攀渀 瀀漀猀猀椀戀氀攀 琀栀愀琀 渀漀渀 唀䔀䘀䤀 洀愀挀栀椀渀攀猀 愀爀攀 挀愀瀀愀戀氀攀㰀戀爀㸀ഀഀ of booting from GPT disks.
਍㰀戀爀㸀ഀഀ We already have seen the limitations of the MBR. GPT based disks are becoming more and more the standard on Intel systems.
਍㰀戀爀㸀ഀഀ Although deviating variants exists, I would say that it's important to remember that:
਍㰀甀氀㸀ഀഀ

Traditional BIOS systems use MBR bootcode and MBR partitioning metadata.

਍㰀氀椀㸀一愀琀椀瘀攀 唀䔀䘀䤀 洀愀挀栀椀渀攀猀 ⠀渀攀眀攀爀 砀㘀㐀 愀渀搀 䤀琀愀渀椀甀洀⤀ 甀猀攀 䜀倀吀 愀猀 瀀愀爀琀椀琀椀漀渀椀渀最 洀攀琀愀搀愀琀愀⸀ 吀栀攀 漀渀氀礀 瀀爀攀戀漀漀琀 挀漀搀攀 椀猀 昀爀漀洀 唀䔀䘀䤀⸀㰀戀爀㸀ഀഀ

Traditional BIOS systems using MBR, can (easily) use GPT disks as data disks.
਍㰀氀椀㸀䄀渀搀⸀⸀ 椀渀搀攀攀搀 椀琀✀猀 瀀漀猀猀椀戀氀攀 琀漀 甀猀攀 䴀䈀刀 愀渀搀 愀 䔀䘀䤀 匀礀猀琀攀洀 倀愀爀琀椀琀椀漀渀⸀㰀戀爀㸀ഀഀ ਍㰀戀爀㸀ഀഀ
਍㰀戀爀㸀ഀഀ ਍㰀栀爀⼀㸀ഀഀ

Chapter 4. A VERY SHORT SECTION ON SOME SCSI TERMS.

਍㰀栀爀⼀㸀ഀഀ ਍ഀഀ This very short section, will just focus on few concepts related to SCSI, namely addressing and paths.
਍㰀戀爀㸀ഀഀ Undoubtly, with any OS using SCSI, you will encounter addressing paths like for example "[1:0:1:0]".
਍䈀甀琀 眀栀愀琀 椀猀 椀琀㼀 䤀琀✀猀 爀攀愀氀氀礀 攀砀琀爀攀洀攀氀礀 猀椀洀瀀氀攀⸀㰀戀爀㸀ഀഀ
਍䤀琀✀猀 愀氀氀 愀戀漀甀琀 漀渀 栀漀眀 琀漀 ∀爀攀愀挀栀∀ 愀渀礀 ∀攀渀搀 搀攀瘀椀挀攀∀Ⰰ 琀栀愀琀 椀猀㨀 昀爀漀洀 眀栀椀挀栀 愀搀愀瀀琀攀爀Ⰰ 眀栀椀挀栀 戀甀猀Ⰰ 眀栀椀挀栀 琀愀爀最攀琀Ⰰ㰀戀爀㸀ഀഀ and lastly (and optionally) which LUN do we want to address?
਍㰀戀爀㸀ഀഀ Sure, the SCSI protocol (and bus) has it's complexities, but for this note we can keep it really that simple.
਍䐀漀渀✀琀 昀漀爀最攀琀 琀栀愀琀 椀琀 椀猀 樀甀猀琀 愀 猀攀琀 漀昀 爀甀氀攀猀 愀渀搀 挀漀洀洀愀渀搀猀⸀ 䤀渀 漀琀栀攀爀 眀漀爀搀猀㨀 椀琀✀猀 愀 瀀爀漀琀漀挀漀氀⸀㰀戀爀㸀ഀഀ So, definitions were described too, on how to address devices (targets) and sub-devices (LUNs) on the bus. That's all.
਍㰀戀爀㸀ഀഀ Now, since a computer might have multiple SCSI cards, and since any card might have multiple ports (thus buses),
਍愀 ∀昀甀氀氀礀 焀甀愀氀椀昀椀攀搀∀ 瀀愀琀栀 琀漀 愀渀礀 猀甀戀搀攀瘀椀挀攀 最漀攀猀 氀椀欀攀㨀㰀戀爀㸀ഀഀ
਍匀䌀匀䤀 氀愀渀最甀愀最攀㨀 㰀䈀㸀愀搀愀瀀琀攀爀⌀Ⰰ 挀栀愀渀渀攀氀⌀Ⰰ 猀挀猀椀 椀搀Ⰰ 氀甀渀⌀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
਍愀渀搀 昀漀爀 攀砀愀洀瀀氀攀 椀洀瀀氀攀洀攀渀琀攀搀 椀渀 唀渀椀砀⼀䰀椀渀甀砀㰀戀爀㸀ഀഀ
਍唀渀椀砀⼀䰀椀渀甀砀㨀 㰀䈀㸀䠀漀猀琀⌀Ⰰ 戀甀猀⌀Ⰰ 琀愀爀最攀琀⌀Ⰰ 氀甀渀⌀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
਍䘀椀最⸀ ㄀　⸀ 匀䌀匀䤀 挀漀渀琀爀漀氀氀攀爀 眀椀琀栀 戀甀猀Ⰰ 琀愀爀最攀琀猀⸀㰀戀爀㸀ഀഀ
਍㰀椀洀最 猀爀挀㴀∀搀椀猀欀搀攀瘀椀挀攀猀㤀⸀樀瀀最∀ 愀氀椀最渀㴀∀挀攀渀琀爀攀∀⼀㸀ഀഀ
਍㰀戀爀㸀ഀഀ The figure above illustrates an old-fashioned "SCSI card", or also called "SCSI controller".
਍䠀漀眀攀瘀攀爀Ⰰ 眀椀琀栀 爀攀猀瀀攀挀琀 琀漀 愀搀搀爀攀猀猀椀渀最 漀昀 猀琀漀爀愀最攀Ⰰ 琀栀攀 洀漀猀琀 挀漀洀洀漀渀 ∀渀愀洀攀∀ 昀漀爀 猀甀挀栀 愀 挀愀爀搀 椀猀 㰀䈀㸀∀䠀䈀䄀∀㰀⼀䈀㸀 ⠀䠀漀猀琀 䈀甀猀 䄀搀愀瀀琀攀爀⤀⸀㰀戀爀㸀ഀഀ
਍一漀眀Ⰰ 眀椀琀栀 爀攀猀瀀攀挀琀 琀漀 㰀䤀㸀搀攀瘀椀挀攀 愀搀搀爀攀猀猀椀渀最㰀⼀䤀㸀 琀栀攀 眀愀礀 琀漀 愀搀搀爀攀猀猀 搀攀瘀椀挀攀猀 椀猀 渀漀琀 洀甀挀栀 搀椀昀昀攀爀攀渀琀 眀栀攀渀 礀漀甀 挀漀洀瀀愀爀攀㰀戀爀㸀ഀഀ a true physical SCSI bus, to for example a fiber based FC LAN, which connects your system to SCSI disks.
਍㰀戀爀㸀ഀഀ How does it look like?
਍㰀戀爀㸀ഀഀ => Example 1: On LInux you might see stuff like:
਍㰀戀爀㸀ഀഀ ਍ⴀⴀ 氀椀猀琀 搀攀瘀椀挀攀猀㨀㰀戀爀㸀ഀഀ
਍嬀爀漀漀琀䀀猀琀愀爀戀漀猀猀 琀洀瀀崀⌀ 挀愀琀 ⼀瀀爀漀挀⼀猀挀猀椀⼀猀挀猀椀㰀戀爀㸀ഀഀ
਍䄀琀琀愀挀栀攀搀 搀攀瘀椀挀攀猀㨀㰀戀爀㸀ഀഀ Host: scsi0 Channel: 00 Id: 00 Lun: 00
਍⸀⸀嘀攀渀搀漀爀㨀 䠀倀⸀⸀⸀䴀漀搀攀氀㨀 䠀匀嘀㈀㄀　⸀⸀⸀刀攀瘀㨀 㘀㈀㈀　㰀戀爀㸀ഀഀ ..Type:...RAID.................ANSI SCSI revision: 05
਍㰀䈀㸀䠀漀猀琀㨀 猀挀猀椀　 䌀栀愀渀渀攀氀㨀 　　 䤀搀㨀 　　 䰀甀渀㨀 　㄀㰀⼀䈀㸀㰀戀爀㸀ഀഀ ..Vendor: HP...Model: HSV210...Rev: 6220
਍⸀⸀吀礀瀀攀㨀⸀⸀⸀䐀椀爀攀挀琀ⴀ䄀挀挀攀猀猀⸀⸀⸀⸀⸀⸀⸀⸀䄀一匀䤀 匀䌀匀䤀 爀攀瘀椀猀椀漀渀㨀 　㔀㰀戀爀㸀ഀഀ Host: scsi0 Channel: 00 Id: 00 Lun: 02
਍⸀⸀嘀攀渀搀漀爀㨀 䠀倀⸀⸀⸀䴀漀搀攀氀㨀 䠀匀嘀㈀㄀　⸀⸀⸀刀攀瘀㨀 㘀㈀㈀　㰀戀爀㸀ഀഀ ..Type:...Direct-Access........ANSI SCSI revision: 05
਍攀琀挀⸀⸀㰀戀爀㸀ഀഀ
਍ⴀⴀ 氀椀猀琀 愀搀愀瀀琀攀爀猀 ⠀栀漀猀琀猀⤀ 氀椀欀攀 䘀䌀 䠀䈀䄀 挀愀爀搀猀㨀㰀戀爀㸀ഀഀ
਍⌀ 氀猀 ⴀ愀氀 ⼀猀礀猀⼀挀氀愀猀猀⼀猀挀猀椀开栀漀猀琀㰀戀爀㸀ഀഀ
਍嬀爀漀漀琀䀀猀琀愀爀戀漀猀猀 縀崀⌀ 氀猀 ⴀ愀氀 ⼀猀礀猀⼀挀氀愀猀猀⼀猀挀猀椀开栀漀猀琀㰀戀爀㸀ഀഀ total 0
਍搀爀眀砀爀ⴀ砀爀ⴀ砀  㤀 爀漀漀琀 爀漀漀琀 　 匀攀瀀 ㈀㄀ ㄀㐀㨀㔀㤀 ⸀㰀戀爀㸀ഀഀ drwxr-xr-x 39 root root 0 Sep 21 14:59 ..
਍搀爀眀砀爀ⴀ砀爀ⴀ砀  ㈀ 爀漀漀琀 爀漀漀琀 　 匀攀瀀 ㈀㄀ ㄀㐀㨀㔀㤀 栀漀猀琀　㰀戀爀㸀ഀഀ drwxr-xr-x 2 root root 0 Sep 21 14:59 host1
਍搀爀眀砀爀ⴀ砀爀ⴀ砀  ㈀ 爀漀漀琀 爀漀漀琀 　 匀攀瀀 ㈀㄀ ㄀㐀㨀㔀㤀 栀漀猀琀㈀㰀戀爀㸀ഀഀ
਍㰀戀爀㸀ഀഀ ਍㴀㸀 䔀砀愀洀瀀氀攀 ㈀㨀 伀渀 嘀䴀圀愀爀攀Ⰰ 礀漀甀 洀椀最栀琀 猀攀攀 猀琀甀昀昀 氀椀欀攀㨀㰀戀爀㸀ഀഀ
਍㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀甀攀∀㸀ഀഀ # cd /vmfs/devices/disks
਍⌀ 氀猀 瘀洀栀⨀㰀戀爀㸀ഀഀ ਍㰀戀爀㸀ഀഀ ਍瘀洀栀戀愀　㨀　㨀　㨀　㰀戀爀㸀ഀഀ vmhba0:0:41:0
਍瘀洀栀戀愀　㨀　㨀㔀㌀㨀　㰀戀爀㸀ഀഀ
਍ഀഀ
਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ => Example 3: On HPUX, you might see stuff like:
਍㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀甀攀∀㸀ഀഀ
਍⌀ 椀漀猀挀愀渀 ⴀ昀渀䌀 攀砀琀开戀甀猀㰀戀爀㸀ഀഀ
਍攀砀琀开戀甀猀⸀⸀㄀㔀⸀⸀　⼀㈀⼀　⼀　⸀㰀䈀㸀㈀⸀㄀⸀　⸀㄀㰀⼀䈀㸀⸀⸀⸀昀挀瀀愀爀爀愀礀⸀䌀䰀䄀䤀䴀䔀䐀⸀⸀䤀一吀䔀刀䘀䄀䌀䔀⸀⸀⸀䘀䌀倀 䄀爀爀愀礀 䤀渀琀攀爀昀愀挀攀㰀戀爀㸀ഀഀ
਍一漀琀攀 琀栀攀 猀琀爀椀渀最 椀渀 ∀戀漀氀搀∀ 眀栀椀挀栀 椀猀 愀最愀椀渀 愀 匀䌀匀䤀 愀搀搀爀攀猀猀Ⰰ 愀猀 愀 瀀愀爀琀 漀昀 愀 昀甀氀氀 ∀栀愀爀搀眀愀爀攀 瀀愀琀栀∀⸀㰀戀爀㸀ഀഀ
਍㰀戀爀㸀ഀഀ ਍䤀昀 礀漀甀爀 猀礀猀琀攀洀 椀猀 挀漀渀渀攀挀琀攀搀 琀漀 愀渀 䘀䌀ⴀ 漀爀 椀匀䌀匀䤀 匀䄀一Ⰰ 礀漀甀 眀椀氀氀 猀攀攀 漀渀攀 漀爀 洀漀爀攀 搀攀瘀椀挀攀猀 渀愀洀攀猀Ⰰ 瀀爀漀戀愀戀氀礀 愀氀猀漀 椀搀攀渀琀椀昀椀攀爀猀㰀戀爀㸀ഀഀ like "1:0:2:0" as in example 1, or denoted slightly otherwise like for example "adaptername0:C0:T0:L0" as in example2.
਍一漀琀攀㨀 椀渀 洀愀渀礀 匀䄀一猀 琀栀攀 ∀吀∀ 洀椀最栀琀 爀攀昀攀爀 琀漀 琀栀攀 ∀稀漀渀椀渀最 琀愀爀最攀琀⼀渀甀洀戀攀爀∀Ⰰ 戀甀琀 琀栀攀 椀搀攀愀 猀琀愀礀猀 焀甀椀琀攀 琀攀 猀愀洀攀⸀㰀戀爀㸀ഀഀ
਍䤀 栀漀瀀攀 椀琀 最攀琀猀 挀氀攀愀爀 琀栀愀琀 椀渀 洀漀猀琀 伀匀✀猀攀猀Ⰰ 琀栀攀 愀搀搀爀攀猀猀 椀猀 愀氀眀愀礀猀 爀攀挀欀漀最渀椀稀愀戀氀攀 愀猀㨀㰀戀爀㸀ഀഀ
਍㰀䈀㸀∀栀漀猀琀⌀㨀戀甀猀⌀㨀琀愀爀最攀琀⌀㨀氀甀渀⌀∀㰀⼀䈀㸀 漀爀 㰀䈀㸀∀愀搀愀瀀琀攀爀⌀㨀挀栀愀渀渀攀氀⌀㨀猀挀猀椀䤀䐀⌀㨀氀甀渀⌀∀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
਍吀栀椀猀 琀栀攀渀 爀攀瀀爀攀猀攀渀琀猀 琀栀攀 愀搀搀爀攀猀猀 漀昀 愀 䰀唀一 ⠀漀爀 ∀搀椀猀欀∀⤀ 昀爀漀洀 愀 䘀䌀 漀爀 椀匀䌀匀䤀 匀䄀一⸀㰀戀爀㸀ഀഀ
਍一漀眀Ⰰ 礀漀甀 洀椀最栀琀 猀漀洀攀琀椀洀攀猀 漀戀猀攀爀瘀攀 猀攀瘀攀爀愀氀 ∀　∀ ⠀稀攀爀漀猀⤀ 椀渀 猀甀挀栀 愀 椀搀攀渀琀椀昀椀攀爀Ⰰ 戀甀琀 琀栀愀琀 挀漀洀攀猀 昀爀漀洀 琀栀攀 昀愀挀琀 琀栀愀琀 琀栀攀 昀椀爀猀琀 挀漀渀琀爀漀氀氀攀爀 椀猀 ∀栀漀猀琀　∀Ⰰ㰀戀爀㸀ഀഀ the first bus is "bus0" etc... Also, LUNs start numbering as of "0".
਍㰀戀爀㸀ഀഀ Now, a "target" is the device the SCSI bus will address first. Maybe to know the address the target, is sufficient, since
਍琀栀愀琀 洀椀最栀琀 戀攀 琀栀攀 ∀攀渀搀 搀攀瘀椀挀攀∀ 椀琀猀攀氀昀㨀 椀琀 搀漀攀猀 渀漀琀 栀愀瘀攀 愀渀礀 猀甀戀搀攀瘀椀挀攀猀 ∀椀渀猀椀搀攀∀⸀㰀戀爀㸀ഀഀ Don't forget that there exists many sorts of devices which can be placed on a SCSI bus.
਍㰀戀爀㸀ഀഀ However, in Storage, the target often is a complex device which manages many subdevices.
਍䤀渀 猀甀挀栀 愀 挀愀猀攀Ⰰ 㰀䤀㸀眀攀 搀漀 栀愀瘀攀 猀甀戀搀攀瘀椀挀攀猀㰀⼀䤀㸀 琀栀愀琀 渀攀攀搀猀 愀渀 猀甀戀愀搀搀爀攀猀猀 琀漀漀 ⠀琀栀攀 䰀唀一 渀甀洀戀攀爀猀⤀⸀㰀戀爀㸀 ഀഀ This is more or less how the situation often is, in addressing LUNs from a SAN.
਍夀漀甀 洀椀最栀琀 栀愀瘀攀 昀漀甀渀搀 漀渀攀 琀愀爀最攀琀⌀Ⰰ 眀椀琀栀 漀渀攀 漀爀 洀甀氀琀椀瀀氀攀 䰀唀一猀 ∀戀攀氀漀眀∀ 椀琀⸀㰀戀爀㸀ഀഀ
਍一漀琀攀 琀栀愀琀 椀琀 搀漀攀猀 渀漀琀 爀攀愀氀氀礀 洀愀琀琀攀爀 椀昀 礀漀甀 眀漀甀氀搀 栀愀瘀攀 匀䌀匀䤀 挀漀洀洀愀渀搀猀 漀渀 愀 漀氀搀ⴀ昀愀猀栀椀漀渀攀搀 匀䌀匀䤀 戀甀猀Ⰰ 漀爀 椀昀㰀戀爀㸀ഀഀ those commands are just simply encapsulated in a network packet as in iSCSI: the principle stays quite the same.
਍㰀戀爀㸀ഀഀ On a SCSI bus, like shown in figure 10, a path like for example [0:0:1:1], uniquely identifies an object on that Bus.
਍䠀漀眀攀瘀攀爀Ⰰ 椀渀 愀 琀礀瀀椀挀愀氀 匀䄀一 猀椀琀甀愀琀椀漀渀Ⰰ 眀攀 栀愀瘀攀 洀甀氀琀椀瀀氀攀 䠀漀猀琀猀Ⰰ 挀漀渀渀攀挀琀攀搀 琀漀 猀眀椀琀挀栀攀猀Ⰰ 眀栀椀挀栀 琀栀攀洀猀攀氀瘀攀猀 愀爀攀 挀漀渀渀攀挀琀攀搀㰀戀爀㸀ഀഀ to Storage controllers. In this situation, we cannot uniquely identify for example a HBA on a Host.
਍䤀昀 礀漀甀 栀愀瘀攀 洀甀氀琀椀瀀氀攀 䠀漀猀琀猀Ⰰ 愀氀氀 眀椀琀栀 愀 䠀䈀䄀 挀愀氀氀攀搀 ∀栀漀猀琀　∀Ⰰ 礀漀甀 挀愀渀渀漀琀 甀渀椀焀甀攀氀礀 椀搀攀渀琀椀昀礀 挀漀洀洀甀渀椀挀愀琀椀漀渀 瀀愀爀琀渀攀爀猀⸀㰀戀爀㸀ഀഀ That's why extended addressing have been applied in SANs, using socalled "WWPN addresses".
਍吀栀椀猀 眀椀氀氀 戀攀 琀栀攀 猀甀戀樀攀挀琀 漀昀 琀栀攀 渀攀砀琀 挀栀愀瀀琀攀爀⸀㰀戀爀㸀ഀഀ ਍㰀戀爀㸀ഀഀ
਍㰀戀爀㸀ഀഀ ਍㰀栀爀⼀㸀ഀഀ

Chapter 5. "World Wide" Identifiers.

਍㰀栀爀⼀㸀ഀഀ ਍ഀഀ Suppose you would have a computersystem, with a HBA installed, which connects the system to a number
਍漀昀 氀漀挀愀氀 琀愀爀最攀琀猀 甀猀椀渀最 愀 琀爀愀搀椀琀椀漀渀愀氀 匀䌀匀䤀 戀甀猀 ⠀漀爀 挀栀愀渀渀攀氀⤀⸀ 䨀甀猀琀 氀椀欀攀 椀渀 昀椀最甀爀攀 ㄀　⸀㰀戀爀㸀ഀഀ
਍㰀䈀㸀䤀渀 猀甀挀栀 愀 挀愀猀攀Ⰰ 琀栀攀 愀搀搀爀攀猀猀椀渀最 猀挀栀攀洀攀 漀昀 䌀栀愀瀀琀攀爀 㐀 眀漀甀氀搀 戀攀 昀甀氀氀礀 猀甀昀昀椀挀椀攀渀琀Ⰰ 戀攀挀愀甀猀攀 椀渀 琀栀愀琀 攀砀愀洀瀀氀攀Ⰰ 愀渀礀 搀攀瘀椀挀攀 挀愀渀㰀戀爀㸀ഀഀ be uniquely addressed (and identified).
਍㰀戀爀㸀ഀഀ Now, in contrast, imaging a number of Servers connected to switches, while those switches themselves are connected
਍琀漀 匀䄀一猀⸀㰀戀爀㸀ഀഀ In such a case, ServerA has a HBA called "host0", but the same is true for any other Server like Server B.
਍匀漀Ⰰ 匀攀爀瘀攀爀䈀 洀椀最栀琀 栀愀瘀攀 愀 䠀䈀䄀 挀愀氀氀攀搀 ∀栀漀猀琀　∀ 琀漀漀⸀㰀戀爀㸀ഀഀ
਍夀漀甀 猀攀攀㼀㰀戀爀㸀ഀഀ
਍㰀䈀㸀ഀഀ In a larger environment we need an "extended addressing scheme", in order to be able to really distinguish
਍戀攀琀眀攀攀渀 琀栀攀 搀椀昀昀攀爀攀渀琀 䠀䈀䄀✀猀 漀渀 琀栀攀 搀椀昀昀攀爀攀渀琀 匀攀爀瘀攀爀猀Ⰰ 愀渀搀 愀氀氀 漀琀栀攀爀 搀攀瘀椀挀攀猀 氀椀欀攀 琀栀攀 猀眀椀琀挀栀 瀀漀爀琀猀 椀渀瘀漀氀瘀攀搀Ⰰ 琀栀攀 匀䄀一 瀀漀爀琀猀 椀渀瘀漀氀瘀攀搀 攀琀挀⸀⸀㰀戀爀㸀ഀഀ ਍㰀戀爀㸀ഀഀ ਍一漀琀攀㨀㰀戀爀㸀ഀഀ Before we go any further, well known other examples are close at hand. For example, you probably know that any netcard
਍椀猀 猀甀瀀瀀漀猀攀搀 琀漀 栀愀瘀攀 愀 甀渀椀焀甀攀 䴀䄀䌀 愀搀搀爀攀猀猀Ⰰ 琀漀 椀搀攀渀琀椀昀礀 椀琀 甀渀椀焀甀攀氀礀 漀渀 琀栀攀 渀攀琀眀漀爀欀⸀ 䄀氀猀漀Ⰰ 樀甀猀琀 氀漀漀欀 愀琀 琀栀攀 椀渀琀攀爀渀攀琀㨀㰀戀爀㸀ഀഀ any Host is supposed to have a unique IP address just to make sure that the "sender" and the "receipient" of data are uniquely defined.
਍㰀戀爀㸀ഀഀ Key point is: in any network, every device should be able to be identified uniquely, which is not possible if for example
਍漀渀氀礀 渀愀洀攀猀 氀椀欀攀 ∀栀漀猀琀　∀ 椀猀 甀猀攀搀⸀ 儀甀攀猀琀椀漀渀猀 氀椀欀攀 ∀眀栀椀挀栀 栀漀猀琀　 ⠀栀戀愀⤀ 漀渀 眀栀椀挀栀 匀攀爀瘀攀爀∀ 眀漀甀氀搀 愀爀椀猀攀 椀洀洀攀搀椀愀琀攀氀礀⸀㰀戀爀㸀ഀഀ
਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ ਍吀栀愀琀✀猀 眀栀礀 最氀漀戀愀氀氀礀 甀渀椀焀甀攀 ∀圀漀爀氀搀 圀椀搀攀∀ 䤀䐀✀猀 眀攀爀攀 椀渀琀爀漀搀甀挀攀搀⸀㰀戀爀㸀ഀഀ
਍㰀戀爀㸀ഀഀ ਍ഀഀ

5.1 Addressing in Fiber Channel:

਍ഀഀ ਍ഀഀ Just like in networking, where on a subnet the networkcard MAC addresses of all devices is essential for communication,
਍琀栀攀 猀愀洀攀 椀搀攀愀 栀愀瘀攀 戀攀攀渀 愀瀀瀀氀椀攀搀 椀渀 䘀䌀 匀䄀一 渀攀琀眀漀爀欀猀⸀㰀戀爀㸀ഀഀ
਍㰀甀氀㸀ഀഀ

Every "device" like a HBA (on a Host), or SAN controller, has it's unique WWNN (Word Wide Node Number).

਍㰀氀椀㸀䈀甀琀Ⰰ 愀 搀攀瘀椀挀攀 洀椀最栀琀 栀愀瘀攀 漀渀攀Ⰰ 漀爀 攀瘀攀渀 洀甀氀琀椀瀀氀攀 ∀瀀漀爀琀猀∀⸀ 吀栀愀琀✀猀 眀栀礀 愀 愀猀猀漀挀椀愀琀攀搀 琀漀 琀栀攀 搀攀瘀椀挀攀✀猀 圀圀一一Ⰰ 㰀唀㸀攀愀挀栀 瀀漀爀琀㰀⼀唀㸀㰀戀爀㸀ഀഀ has it's derived WWPN (Word Wide Port Number). ਍㰀氀椀㸀䄀 匀䄀一 挀漀渀琀爀漀氀氀攀爀⼀昀椀氀攀爀 ⠀洀愀渀愀最椀渀最 搀椀猀欀愀爀爀愀礀猀⤀ 栀愀猀 愀 圀圀一一Ⰰ 愀渀搀 椀琀 栀愀猀 漀渀攀 漀爀 洀漀爀攀 瀀漀爀琀猀 琀漀漀Ⰰ 攀愀挀栀 眀椀琀栀 椀琀✀猀 漀渀 圀圀倀一⸀㰀⼀氀椀㸀ഀഀ

Ultimately, traffic goes from WWPN to WWPN (Host to/from SAN) with optional switches in between.

਍㰀⼀甀氀㸀ഀഀ ਍吀栀攀 昀漀爀洀愀琀 漀昀 愀 圀圀倀一㨀㰀戀爀㸀ഀഀ
਍䄀 圀圀倀一 椀猀 猀漀爀琀 漀昀 琀栀攀 ∀䴀䄀䌀 攀焀甀椀瘀愀氀攀渀琀∀ 椀渀 愀 匀䄀一 渀攀琀眀漀爀欀⸀ 䤀琀✀猀 愀 㠀 戀礀琀攀 椀搀攀渀琀椀昀椀攀爀⸀㰀戀爀㸀ഀഀ Here is an example WWPN: "2135-3900-f027-6769". This could also be denoted without the hyphens, like "21353900f0276769",
਍漀爀 眀椀琀栀 愀 ∀㨀∀ 戀攀琀眀攀攀渀 攀愀挀栀 戀礀琀攀 ⠀琀眀漀 搀椀最椀琀猀⤀Ⰰ 氀椀欀攀 ∀㈀㄀㨀㌀㔀㨀㌀㤀㨀　　㨀昀　㨀㈀㜀㨀㘀㜀㨀㘀㤀∀⸀ 㰀戀爀㸀ഀഀ
਍匀漀洀攀 漀爀最愀渀椀稀愀琀椀漀渀 栀愀猀 琀漀 欀攀攀瀀 愀渀 ∀攀礀攀∀ 漀渀 琀栀攀 瀀漀猀猀椀戀氀攀 圀圀倀一猀Ⰰ 椀渀 漀爀搀攀爀 琀漀 眀愀爀爀愀渀琀 甀渀椀焀甀攀渀攀猀猀⸀ 吀栀椀猀 椀猀 琀栀攀 䤀䔀䔀䔀⸀㰀戀爀㸀ഀഀ
਍圀栀攀渀 愀 䴀愀渀甀昀愀挀琀甀爀攀爀 眀愀渀琀猀 琀漀 瀀爀漀搀甀挀攀 䘀䌀 栀愀爀搀眀愀爀攀Ⰰ 椀琀 栀愀猀 琀漀 爀攀最椀猀琀攀爀 眀椀琀栀 琀栀攀 䤀䔀䔀䔀 昀漀爀 愀 ㌀ 戀礀琀攀 ∀伀唀䤀∀ 椀搀攀渀琀椀昀椀攀爀Ⰰ 眀栀椀挀栀Ⰰ 眀栀攀渀 最爀愀渀琀攀搀Ⰰ㰀戀爀㸀ഀഀ will be part of the WWPNs in all their products. This OUI is then unique per Manufacturer.
਍㰀戀爀㸀ഀഀ There is a certain structure in any WWPN. A WWPN is derived from it's parent WWNN (of the device).
਍㰀戀爀㸀ഀഀ Let's see how to find WWPNs on a few example platforms:
਍㰀戀爀㸀ഀഀ
਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀爀攀搀∀㸀ഀഀ ਍㰀栀㌀㸀㔀⸀㈀ 䄀 昀攀眀 攀砀愀洀瀀氀攀猀 漀昀 昀椀渀搀椀渀最 圀圀倀一猀 漀渀 猀漀洀攀 攀砀愀洀瀀氀攀 瀀氀愀琀昀漀爀洀猀㨀㰀⼀栀㌀㸀ഀഀ ਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ ਍㰀䈀㸀㰀唀㸀䔀砀愀洀瀀氀攀 ㄀㨀 䰀椀渀甀砀㨀㰀⼀唀㸀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
਍伀渀 䰀椀渀甀砀Ⰰ 瀀攀漀瀀氀攀 漀昀琀攀渀 甀猀攀 琀栀攀 ∀儀䰀漀最椀挀∀ 愀搀愀瀀琀攀爀猀 ⠀焀氀愀 搀爀椀瘀攀爀猀⤀ 漀爀 ∀䔀洀甀氀攀砀∀ 愀搀愀瀀琀攀爀猀 ⠀氀瀀昀挀 搀爀椀瘀攀爀⤀⸀㰀戀爀㸀ഀഀ
਍夀漀甀 洀椀最栀琀 琀爀礀㨀㰀戀爀㸀ഀഀ
਍⠀㄀⤀㨀㰀戀爀㸀ഀഀ # ls -al /proc/scsi/adapter_type/n
਍㰀戀爀㸀ഀഀ Where adapter_type is the host adapter type and n is the host adapter number for your card.
਍㰀戀爀㸀ഀഀ (2):
਍䤀昀 昀漀爀 礀漀甀爀 愀搀愀瀀琀攀爀Ⰰ 琀栀攀 洀漀爀攀 洀漀搀攀爀渀 ∀猀礀猀昀猀∀ 爀攀最椀猀琀爀愀琀椀漀渀 栀愀瘀攀 戀攀攀渀 椀洀瀀氀攀洀攀渀琀攀搀Ⰰ 戀爀漀眀猀攀 愀爀漀甀渀搀 椀渀 ∀⼀猀礀猀⼀挀氀愀猀猀⼀猀挀猀椀开栀漀猀琀⼀栀漀猀琀渀∀ 漀爀 猀甀戀搀椀爀猀Ⰰ㰀戀爀㸀ഀഀ or in "/sys/class/fc_host". In the latter, you then probably find an entry called "port_name".
਍㰀戀爀㸀ഀഀ (3):
਍伀爀 琀愀欀攀 愀 氀漀漀欀 椀渀 ∀⼀瘀愀爀⼀氀漀最⼀洀攀猀猀愀最攀猀∀Ⰰ 猀椀渀挀攀 眀攀 猀栀漀甀氀搀 猀攀攀 琀栀攀 愀搀愀瀀琀攀爀 洀漀搀甀氀攀猀 戀攀 氀漀愀搀攀搀 愀琀 戀漀漀琀琀椀洀攀㨀㰀戀爀㸀ഀഀ
਍㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀甀攀∀㸀ഀഀ ਍⌀ 挀愀琀 ⼀瘀愀爀⼀氀漀最⼀洀攀猀猀愀最攀猀㰀戀爀㸀ഀഀ ...
਍䐀攀挀 ㄀㔀 　㤀㨀㐀　㨀㄀　 猀琀愀爀最愀琀攀 欀攀爀渀攀氀㨀 ⠀猀挀猀椀⤀㨀 䘀漀甀渀搀 愀 儀䰀䄀㈀㈀　　 䀀 戀甀猀 ㄀Ⰰ 搀攀瘀椀挀攀 　砀㄀Ⰰ 椀爀焀 ㈀　Ⰰ 椀漀戀愀猀攀 　砀㈀㌀　　㰀戀爀㸀ഀഀ ..
਍䐀攀挀 ㄀㔀 　㤀㨀㐀　㨀㄀　 猀琀愀爀最愀琀攀 欀攀爀渀攀氀㨀 猀挀猀椀ⴀ焀氀愀㄀ⴀ愀搀愀瀀琀攀爀ⴀ渀漀搀攀㴀㈀　　　　　攀　㠀戀　㈀攀㔀㌀㐀㬀㰀戀爀㸀ഀഀ Dec 15 09:40:10 stargate kernel: scsi-qla1-adapter-port=210000e08b02e534;
਍䐀攀挀 ㄀㔀 　㤀㨀㐀　㨀㄀　 猀琀愀爀最愀琀攀 欀攀爀渀攀氀㨀 猀挀猀椀ⴀ焀氀愀㄀ⴀ琀愀爀最攀琀ⴀ　㴀㔀　　㔀　㜀㘀㌀　　挀　㠀戀㄀昀㬀㰀戀爀㸀ഀഀ ..
਍㰀戀爀㸀ഀഀ ਍㰀戀爀㸀ഀഀ Example 2: AIX
਍㰀戀爀㸀ഀഀ It depends a bit which driver stack you have loaded (like SDD), but here are a few examples, just for illustrational purposes:
਍㰀戀爀㸀ഀഀ ਍ഀഀ # datapath query wwpn
਍㰀戀爀㸀ഀഀ Adapter Name....PortWWN
਍昀猀挀猀椀　⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀㄀　　　　　　　䌀㤀㐀䘀㤀㄀䌀䐀㰀戀爀㸀ഀഀ fscsi1..........10000000C94F9923
਍㰀戀爀㸀ഀഀ or
਍㰀戀爀㸀ഀഀ # lscfg -lv fcs0
਍㰀戀爀㸀ഀഀ fcs0...............U7879.001.DQDKCPR-P1-C2-T1..FC Adapter
਍㰀戀爀㸀ഀഀ ...Part Number.................03N6441
਍⸀⸀⸀䔀䌀 䰀攀瘀攀氀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀䄀㰀戀爀㸀ഀഀ ...Serial Number...............1D54508045
਍⸀⸀⸀䴀愀渀甀昀愀挀琀甀爀攀爀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀　　㄀䐀㰀戀爀㸀ഀഀ ...Feature Code................280B
਍⸀⸀⸀䘀刀唀 一甀洀戀攀爀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀ 　㌀一㘀㐀㐀㄀㰀戀爀㸀ഀഀ ...Device Specific.(ZM)........3
਍⸀⸀⸀一攀琀眀漀爀欀 䄀搀搀爀攀猀猀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀⸀㄀　　　　　　　䌀㤀㐀䘀㤀㄀䌀䐀㰀戀爀㸀ഀഀ ...ROS Level and ID............0288193D
਍㰀戀爀㸀ഀഀ A lot of other output omitted...
਍ഀഀ ਍㰀戀爀㸀ഀഀ
਍㰀䈀㸀㰀唀㸀䔀砀愀洀瀀氀攀 ㌀㨀 圀椀渀搀漀眀猀㰀⼀唀㸀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
਍䄀最愀椀渀Ⰰ 椀琀 搀攀瀀攀渀搀猀 愀 戀椀琀 漀昀 眀栀椀挀栀 搀爀椀瘀攀爀 愀渀搀 䘀䌀 䌀愀爀搀 礀漀甀 甀猀攀⸀ 䴀愀礀戀攀Ⰰ 眀椀琀栀 礀漀甀爀 䌀愀爀搀Ⰰ 猀漀洀攀 甀琀椀氀琀礀 眀愀猀 瀀爀漀瘀椀搀攀搀 琀漀漀⸀㰀戀爀㸀ഀഀ Here is just an example for illustrational purposes:
਍㰀戀爀㸀ഀഀ ਍䌀㨀尀㸀 昀挀焀甀攀爀礀㰀戀爀㸀ഀഀ
਍挀漀洀⸀攀洀甀氀攀砀ⴀ䰀倀㤀　　㈀ⴀ㄀㨀 倀漀爀琀圀圀一㨀 ㄀　㨀　　㨀　　㨀　　㨀挀㠀㨀㈀㈀㨀搀　㨀㄀㠀 尀尀⸀尀匀挀猀椀㌀㨀 㰀戀爀㸀ഀഀ
਍漀爀 琀栀椀猀 倀漀眀攀爀猀栀攀氀氀 挀漀洀洀愀渀搀氀攀琀 洀椀最栀琀 眀漀爀欀 漀渀 礀漀甀爀 猀礀猀琀攀洀㨀㰀戀爀㸀ഀഀ
਍倀匀 䌀㨀尀㸀 䜀攀琀ⴀ䠀䈀䄀圀椀渀 ⴀ䌀漀洀瀀甀琀攀爀一愀洀攀 䤀倀䄀搀搀爀攀猀猀  簀 䘀漀爀洀愀琀ⴀ吀愀戀氀攀 ⴀ䄀甀琀漀匀椀稀攀㰀戀爀㸀ഀഀ
਍匀攀攀 愀氀猀漀㨀 ∀栀琀琀瀀㨀⼀⼀最愀氀氀攀爀礀⸀琀攀挀栀渀攀琀⸀洀椀挀爀漀猀漀昀琀⸀挀漀洀⼀猀挀爀椀瀀琀挀攀渀琀攀爀⼀䘀椀渀搀ⴀ䠀䈀䄀ⴀ愀渀搀ⴀ圀圀倀一ⴀ㔀㌀㄀㈀㄀㄀㐀　∀㰀戀爀㸀ഀഀ
਍㰀戀爀㸀ഀഀ ਍ഀഀ

5.3 A conceptual representation of SAN connections:

਍ഀഀ ਍ഀഀ Now that we know that ultimately, a HBA port identified by it's WWPN, connects to a Storage controller port dentified by it's WWPN,
਍氀攀琀✀猀 猀攀攀 椀昀 眀攀 挀愀渀 挀愀瀀琀甀爀攀 琀栀愀琀 椀渀 愀 猀椀洀瀀氀攀 昀椀最甀爀攀㨀㰀戀爀㸀ഀഀ
਍䘀椀最⸀ ㄀㄀⸀ 䠀漀猀琀ⴀ匀䄀一 挀漀洀洀甀渀椀挀愀琀椀漀渀㰀戀爀㸀ഀഀ
਍㰀椀洀最 猀爀挀㴀∀搀椀猀欀搀攀瘀椀挀攀猀㄀　⸀樀瀀最∀ 愀氀椀最渀㴀∀挀攀渀琀爀攀∀⼀㸀ഀഀ
਍㰀戀爀㸀ഀഀ While the above sketch focusses on the importance of WWPNs in communication, ofcourse in most SANs,
਍㰀䈀㸀洀甀氀琀椀瀀氀攀㰀⼀䈀㸀 䠀漀猀琀猀 愀爀攀 挀漀渀渀攀挀琀攀搀 ⠀琀栀爀漀甀最栀 漀渀攀 漀爀 洀漀爀攀 猀眀椀琀挀栀攀猀⤀ 琀漀 愀 匀䄀一 挀漀渀琀爀漀氀氀攀爀⸀㰀戀爀㸀ഀഀ Maybe it's nice to show such a figure as well. In the figure below, the left side is a highlevel
਍瘀椀攀眀 漀昀 猀甀挀栀 愀 匀䄀一⸀㰀戀爀㸀ഀഀ
਍䘀椀最⸀ ㄀㈀⸀ 匀欀攀琀挀栀 漀昀 䠀漀猀琀猀 琀漀 䘀䌀 匀䄀一 挀漀渀渀攀挀琀椀漀渀猀Ⰰ 愀渀搀 一䄀匀 渀攀琀眀漀爀欀 挀漀洀洀甀渀椀挀愀琀椀漀渀⸀㰀戀爀㸀ഀഀ
਍㰀椀洀最 猀爀挀㴀∀搀椀猀欀搀攀瘀椀挀攀猀㄀㄀⸀樀瀀最∀ 愀氀椀最渀㴀∀挀攀渀琀爀攀∀⼀㸀ഀഀ
਍㰀戀爀㸀ഀഀ
਍㰀戀爀㸀ഀഀ
਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀甀攀∀㸀ഀഀ

---

਍㰀栀㈀ 椀搀㴀∀猀攀挀琀椀漀渀㘀∀㸀䌀栀愀瀀琀攀爀 㘀⸀ 䈀䰀伀䌀䬀 䤀伀Ⰰ 䘀䤀䰀䔀 䤀伀Ⰰ 䄀一䐀 倀刀伀吀伀䌀伀䰀匀⸀㰀⼀栀㈀㸀ഀഀ

---

਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
਍䰀漀挀愀氀 搀椀猀欀猀 漀爀 氀漀挀愀氀 ⠀匀䌀匀䤀⤀ 搀椀猀欀 愀爀爀愀礀猀Ⰰ 眀漀爀欀 愀琀 琀栀攀 戀氀漀挀欀 䤀⼀伀 氀愀礀攀爀Ⰰ 戀攀氀漀眀 琀栀攀 昀椀氀攀 猀礀猀琀攀洀 氀愀礀攀爀⸀㰀戀爀㸀ഀഀ The same is true for LUNs exposed by iSCSI or FC SANs. For the client OS, they "just look like" local disks
਍愀渀搀 愀爀攀 愀氀猀漀 愀挀挀攀猀猀攀搀 戀礀 戀氀漀挀欀 䤀伀 猀攀爀瘀椀挀攀猀⸀㰀戀爀㸀ഀഀ
਍䌀漀渀琀爀愀爀礀Ⰰ 甀渀椀砀ⴀ氀椀欀攀 一䘀匀 渀攀琀眀漀爀欀 洀漀甀渀琀猀Ⰰ 漀爀 䴀椀挀爀漀猀漀昀琀 匀䴀䈀⼀䌀䤀䘀匀 猀栀愀爀攀猀Ⰰ 漀瀀攀爀愀琀攀 漀渀 琀栀攀 渀攀琀眀漀爀欀 氀愀礀攀爀⸀㰀戀爀㸀ഀഀ File IO commands will see to it that the client OS gets access to the data on those shares.
਍㰀戀爀㸀ഀഀ ਍㰀䈀㸀㰀唀㸀㄀⸀ 䈀氀漀挀欀 䤀伀 眀椀琀栀 琀爀愀搀椀琀椀漀渀愀氀 䘀䌀 愀渀搀 椀匀䌀匀䤀 匀䄀一猀㨀㰀⼀唀㸀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
਍圀栀攀渀 礀漀甀爀 䠀漀猀琀 椀猀 挀漀渀渀攀挀琀攀搀 琀漀 ⠀眀栀愀琀 眀攀 渀漀眀 猀攀攀 愀猀⤀ 愀 琀爀愀搀椀琀椀漀渀愀氀 䘀䌀 匀䄀一Ⰰ 礀漀甀爀 匀攀爀瘀攀爀 洀椀最栀琀 栀愀瘀攀 漀渀攀 漀爀 洀漀爀攀㰀戀爀㸀ഀഀ HBA Fiber cards, which connects to one or more switch(es), which is then further connected to the Storage arrays.
਍㰀戀爀㸀ഀഀ Typically, the elements associated with the transfer of data, are "block address spaces" and "datablocks", and that's why
਍瀀攀漀瀀氀攀 琀愀氀欀 愀戀漀甀琀 㰀䈀㸀∀戀氀漀挀欀 䤀⼀伀 猀攀爀瘀椀挀攀猀∀㰀⼀䈀㸀 眀栀攀渀 搀椀猀挀甀猀猀椀渀最 ⠀琀爀愀搀椀琀椀漀渀愀氀⤀ 匀䄀一✀猀⸀㰀戀爀㸀ഀഀ So, here SCSI block-based protocols are in use, over Fibre Channel (FC)
਍㰀戀爀㸀ഀഀ The same is true in iSCSI, where transfer of block data to hosts occurs, using the SCSI protocol over TCP/IP.
਍㰀戀爀㸀ഀഀ 2. File IO with Shares, Exports, and NAS:
਍㰀戀爀㸀ഀഀ In a network, there might exists "fileshares" exposed by file/print servers (Microsoft), or NFS Servers (Unix/Linux).
਍䠀攀爀攀Ⰰ 礀漀甀爀 爀攀搀椀爀攀挀琀漀爀 挀氀椀攀渀琀 猀漀昀琀眀愀爀攀Ⰰ ∀琀栀椀渀欀猀∀ 椀渀 琀攀爀洀猀 漀昀 ∀昀椀氀攀猀∀ 琀栀愀琀 椀琀 眀愀渀琀 琀漀 爀攀琀爀攀椀瘀攀 漀爀 猀琀漀爀攀 琀漀⼀昀爀漀洀 琀栀攀 匀攀爀瘀攀爀⸀㰀戀爀㸀ഀഀ This network is just a normal network that we all know of. Ofcourse, a file will be transfered by the network protocol, meaning
਍琀栀愀琀 搀愀琀愀 猀攀最洀攀渀琀猀 愀爀攀 攀渀瘀攀氀漀瀀攀搀 戀礀 洀漀爀攀 漀爀 氀攀猀猀 爀攀最甀氀愀爀 渀攀琀眀漀爀欀 瀀愀挀欀攀琀猀Ⰰ 氀椀欀攀 椀渀 愀渀礀 漀琀栀攀爀 渀漀爀洀愀氀 吀䌀倀䤀倀 渀攀琀眀漀爀欀⸀㰀戀爀㸀ഀഀ Since client and Server think in terms of whole files, people speak of File IO Services.
਍㰀戀爀㸀ഀഀ Two main Redirector/Server protocols are often used: CIFS (the well-known SMB from Microsoft) and NFS (Unix/Linux world).
਍㰀戀爀㸀ഀഀ 3. Network Attached Storage (NAS):
਍㰀戀爀㸀ഀഀ A NAS device actually has all features of a regular FileServer. So, it's often used as a CIFS and/or NFS based Server.
਍䤀琀 栀愀猀 猀漀洀攀 昀攀愀琀甀爀攀猀 氀椀欀攀 愀 匀䄀一Ⰰ 猀椀渀挀攀 愀 琀爀甀攀 一䄀匀 搀攀瘀椀挀攀 椀猀 愀氀猀漀 愀 搀攀瘀椀挀攀 眀椀琀栀 愀 挀漀渀琀爀漀氀氀攀爀 愀渀搀 䐀椀猀欀愀爀爀愀礀⠀猀⤀Ⰰ 琀栀甀猀 爀攀猀攀洀戀氀椀渀最 愀 匀䄀一⸀㰀戀爀㸀ഀഀ Obviously, a NAS devices has network ports which connects it to networkdevices (like a switch).
਍䠀漀眀攀瘀攀爀 一䄀匀 挀漀洀攀猀 椀渀 愀 眀椀搀攀 瘀愀爀椀攀琀礀 漀昀 昀漀爀洀猀 愀渀搀 猀栀愀瀀攀猀⸀㰀戀爀㸀ഀഀ
਍㰀戀爀㸀ഀഀ Please take a look again at figure 12. Here, the left side tries to depict a traditional FC SAN, while the part
਍漀渀 琀栀攀 爀椀最栀琀 猀椀搀攀 猀栀漀眀猀 愀 一䄀匀 搀攀瘀椀挀攀 琀栀愀琀✀猀 瀀氀愀挀攀搀 椀渀 愀 ∀爀攀最甀氀愀爀∀ 渀攀琀眀漀爀欀⸀㰀戀爀㸀ഀഀ
਍㰀䈀㸀㰀唀㸀㐀⸀ 䴀漀搀攀爀渀 匀䄀一 挀漀渀琀爀漀氀氀攀爀猀⼀昀椀氀攀爀猀㨀㰀⼀唀㸀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
਍䴀愀渀礀 洀漀搀攀爀渀 挀漀渀琀爀漀氀氀攀爀猀 ⠀漀爀 昀椀氀攀爀猀⤀ 栀愀瘀攀 漀瀀琀椀漀渀猀 昀漀爀 䘀䌀 匀䄀一Ⰰ 愀渀搀 椀匀䌀匀䤀 匀䄀一 椀洀瀀氀攀洀攀渀琀愀琀椀漀渀猀⸀㰀戀爀㸀ഀഀ Obviously FC uses primarily FC cards and FC connectors. However, iSCSI just uses network controllers.
਍䄀渀搀Ⰰ 洀漀搀攀爀渀 昀椀氀攀爀猀 栀愀瘀攀 漀瀀琀椀漀渀猀 琀漀 攀砀瀀漀猀攀 琀栀攀 搀攀瘀椀挀攀 愀猀 愀 一䄀匀 ⠀䌀䤀䘀匀 愀渀搀⼀漀爀 一䘀匀 匀攀爀瘀攀爀⤀ 漀渀 琀栀攀 渀攀琀眀漀爀欀 愀猀 眀攀氀氀⸀㰀戀爀㸀ഀഀ
਍㰀戀爀㸀ഀഀ Some folks used to say: "if it is an Block I/O then it is SAN, if it is an File I/O then it is an NAS" ਍㰀戀爀㸀ഀഀ Nowadays, this is still true, but as we saw above, modern SANs have options to expose it (partly) as a NAS too.
਍㰀戀爀㸀ഀഀ 5. Some main types of SANs:
਍㰀戀爀㸀ഀഀ A number of implementations exists. The most prominent ones are:
਍㰀甀氀㸀ഀഀ

FC-SAN or Fibre Channel Protocol (FCP), usually using a switched Fiber infrastructure, can be seen as a mapping of SCSI over Fibre Channel.

਍㰀氀椀㸀椀匀䌀匀䤀 匀䄀一Ⰰ 甀猀椀渀最 愀 渀攀琀眀漀爀欀 椀渀昀爀愀猀琀爀甀挀琀甀爀攀Ⰰ 挀愀渀 戀攀 猀攀攀渀 愀猀 愀 洀愀瀀瀀椀渀最 漀昀 匀䌀匀䤀 漀瘀攀爀 愀 吀䌀倀䤀倀 渀攀琀眀漀爀欀⸀㰀⼀氀椀㸀ഀഀ

Fibre Channel over Ethernet (FCoE). This is the FCP protocol using network technology.

਍㰀⼀甀氀㸀ഀഀ In Europe, especially FC-SANs and iSCSI SANs are popular, while recently a renewed interest seems to exists in FCoE SANs.
਍㰀戀爀㸀ഀഀ Many other sorts of "storage access" implementations exists, especially remote storage access. Some of those have features that a regular SAN has too
਍氀椀欀攀 昀漀爀 攀砀愀洀瀀氀攀 ∀䘀䤀䌀伀一∀ 椀渀 䤀䈀䴀 洀愀椀渀昀爀愀洀攀 猀琀漀爀愀最攀 琀攀挀栀渀漀氀漀最椀攀猀⸀ 䠀漀眀攀瘀攀爀Ⰰ 椀琀✀猀 渀漀琀 愀氀眀愀礀 挀愀氀氀攀搀 愀 ∀匀䄀一∀⸀㰀戀爀㸀ഀഀ ਍㰀戀爀㸀ഀഀ 6. Note on LUNs:
਍㰀戀爀㸀ഀഀ "NAS" devices, and FileServers, primarily expose "shares" (like Microsoft SMB/CIFS, or NFS on Unix/Linux), where "File IO"
਍椀猀 椀洀瀀氀攀洀攀渀琀攀搀⸀ 匀漀Ⰰ 琀栀攀 ∀甀渀椀琀∀ 琀栀愀琀 甀氀琀椀洀愀琀攀氀礀 最攀琀猀 琀爀愀渀猀昀攀爀爀攀搀 ⠀甀猀椀渀最 渀攀琀眀漀爀欀 瀀愀挀欀攀琀猀⤀Ⰰ 椀猀 愀 昀椀氀攀⸀㰀戀爀㸀ഀഀ
਍䄀 䰀唀一 攀砀瀀漀猀攀搀 戀礀 愀 䘀䌀ⴀ 漀爀 椀匀䌀匀䤀 匀䄀一 ⠀漀爀 䘀䌀漀䔀 匀䄀一⤀Ⰰ 椀猀 愀 戀椀琀 搀椀昀昀攀爀攀渀琀⸀ 䘀漀爀 琀栀攀 䠀漀猀琀 ⠀琀栀攀 挀氀椀攀渀琀⤀Ⰰ 琀栀攀 䰀唀一 愀挀琀猀 樀甀猀琀 愀猀 椀昀㰀戀爀㸀ഀഀ it were a local disk (which it's not ofcourse).
਍匀漀Ⰰ 漀渀挀攀 愀 䰀唀一 椀猀 搀椀猀挀漀瘀攀爀攀搀 漀渀 愀 䠀漀猀琀Ⰰ 礀漀甀 挀愀渀 昀漀爀洀愀琀 椀琀 愀渀搀 挀爀攀愀琀攀 愀 昀椀氀攀猀礀猀琀攀洀Ⰰ 氀椀欀攀 昀漀爀 攀砀愀洀瀀氀攀 挀爀攀愀琀椀渀最 愀 愀 䜀㨀 搀爀椀瘀攀 椀渀 圀椀渀搀漀眀猀Ⰰ㰀戀爀㸀ഀഀ or creating the "/data" filesystem on a Unix/Linux system.
਍一漀琀攀 琀栀愀琀 琀栀椀猀 椀猀 搀椀昀昀攀爀攀渀琀 昀爀漀洀 一䄀匀⸀ 伀渀 愀 一䄀匀Ⰰ 琀栀攀 䠀漀猀琀 ⠀挀氀椀攀渀琀⤀ 漀渀氀礀 愀挀挀攀猀猀攀猀 琀栀攀 猀琀漀爀愀最攀Ⰰ 戀甀琀 椀琀 搀漀攀猀 渀漀琀 昀漀爀洀愀琀 椀琀Ⰰ 愀渀搀㰀戀爀㸀ഀഀ it does not create some sort of preferred filesystem on that NAS based storage.
਍㰀戀爀㸀ഀഀ How the LUN physically is organized on the SAN, often is not known, except for Storage Admins. For example, it could be a "slice", striped over 6 physical disks
਍甀猀椀渀最 猀漀洀攀 刀䄀䤀䐀 椀洀瀀氀攀洀攀渀琀愀琀椀漀渀⸀ 吀栀攀 洀漀爀攀 猀瀀椀渀搀攀氀猀 ⠀搀椀猀欀猀⤀ 愀爀攀 甀猀攀搀 琀漀 猀甀瀀瀀漀爀琀 琀栀攀 䰀唀一Ⰰ 甀猀甀愀氀氀礀Ⰰ 琀栀攀 戀攀琀琀攀爀 琀栀攀 瀀攀爀昀漀爀洀愀渀挀攀 ⠀䤀伀倀匀⤀㰀戀爀㸀ഀഀ will be.
਍㰀戀爀㸀ഀഀ So, although most often LUNs are used for filesystems (where files and directories can be created on in the usual way), sometimes
਍愀 䰀唀一 椀猀 甀猀攀搀 愀猀 愀 ∀爀愀眀∀ 搀攀瘀椀挀攀⸀ 䄀渀 攀砀愀洀瀀氀攀 挀愀渀 戀攀 伀爀愀挀氀攀 ∀䄀匀䴀∀Ⰰ 眀栀攀爀攀 琀栀攀 䰀唀一 挀愀渀渀漀琀 戀攀 搀椀爀攀挀琀氀礀 愀挀挀攀猀猀攀搀 戀礀 琀栀攀 䠀漀猀琀 伀瀀攀爀愀琀椀渀最 匀礀猀琀攀洀Ⰰ㰀戀爀㸀ഀഀ and only Oracle ASM IO services has formatted it to it's proprierty layout, and only ASM "knows" the details on how to access the data on that LUN.
਍ഀഀ ਍㰀戀爀㸀ഀഀ
਍㰀戀爀㸀ഀഀ ਍㰀栀爀⼀㸀ഀഀ

Chapter 7. A FEW NOTES ON VMWARE.

਍㰀栀爀⼀㸀ഀഀ ਍ഀഀ A VMWare ESX / ESXi host, which is a "bare metal" or "physical" machine, is the "home" for a number of "Virtual Machines" (VMs).
਍吀栀攀爀攀 愀爀攀 焀甀椀琀攀 猀漀洀攀 搀椀昀昀攀爀攀渀挀攀猀 戀攀琀眀攀攀渀 䔀匀堀 ㌀⸀砀Ⰰ 愀渀搀 䔀匀堀椀 㐀⼀㔀Ⰰ 愀氀猀漀 眀椀琀栀 爀攀猀瀀攀挀琀 琀漀 猀琀漀爀愀最攀 椀洀瀀氀攀洀攀渀琀愀琀椀漀渀猀⸀㰀戀爀㸀ഀഀ
਍䄀氀漀渀最 愀氀氀 瘀攀爀猀椀漀渀猀Ⰰ 琀栀攀 昀漀氀氀漀眀椀渀最 ∀爀攀搀 氀椀渀攀∀ 挀愀渀 戀攀 搀椀猀挀漀瘀攀爀攀搀⸀㰀戀爀㸀ഀഀ
਍夀漀甀 欀渀漀眀 琀栀愀琀 愀渀 䔀匀堀⠀椀⤀ 䠀漀猀琀Ⰰ 攀猀猀攀渀琀椀愀氀氀礀 爀甀渀猀 嘀椀爀琀甀愀氀 䴀愀挀栀椀渀攀猀 ⠀氀椀欀攀 洀漀猀琀 渀漀琀愀戀氀礀 圀椀渀搀漀眀猀 匀攀爀瘀攀爀猀Ⰰ 䰀椀渀甀砀 匀攀爀瘀攀爀猀⤀⸀㰀戀爀㸀ഀഀ These VMs have one or more "disks", just like their "bare metal" cousins.
਍㰀戀爀㸀ഀഀ However, most cleverly, such a "systemdisk" (like C: of a Windows Server) actually is a ".vmdk" file on
਍猀漀洀攀 猀琀漀爀愀最攀 猀礀猀琀攀洀⸀ 伀昀挀漀甀爀猀攀 琀栀攀爀攀 愀爀攀 愀 昀攀眀 猀甀瀀瀀漀爀琀椀渀最 昀椀氀攀猀 愀猀 眀攀氀氀Ⰰ 戀甀琀 猀甀瀀瀀漀猀攀 眀攀 栀愀瘀攀 愀 圀椀渀搀漀眀猀 嘀䴀 挀愀氀氀攀搀 ∀最漀漀昀礀∀Ⰰ㰀戀爀㸀ഀഀ then somewhere (on some storage) the systemdisk of this machine is just contained in the vmdk file "goofy_flat.vmdk", which
਍琀礀瀀椀挀愀氀氀礀 挀漀甀氀搀 栀愀瘀攀 愀 猀椀稀攀 漀昀 ㈀　䜀䈀 漀爀 猀漀⸀㰀戀爀㸀ഀഀ
਍嘀䴀圀愀爀攀 甀猀攀猀 愀 ∀搀愀琀愀猀琀漀爀攀∀ 昀漀爀 猀琀漀爀愀最攀 漀昀 猀甀挀栀 昀椀氀攀猀 漀昀 琀栀攀 嘀䴀✀猀⸀ 匀甀挀栀 愀 搀愀琀愀猀琀漀爀攀 漀昀琀攀渀 椀猀 猀琀漀爀攀搀 漀渀㰀戀爀㸀ഀഀ a "VMFS (VMware File System) datastore" which could be local disks on the ESXi Host, or it can be found
਍漀渀 愀 一䘀匀 昀椀氀攀猀礀猀琀攀洀⸀ 吀栀椀猀 一䘀匀 猀琀漀爀愀最攀 挀愀渀 戀攀 ∀攀砀瀀漀猀攀搀∀ 戀礀 愀 一䄀匀Ⰰ 漀爀 愀 匀䄀一 愀挀琀椀渀最 愀猀 一䄀匀Ⰰ 漀爀 漀琀栀攀爀 一䘀匀 匀攀爀瘀攀爀⸀㰀戀爀㸀ഀഀ
਍䠀漀眀攀瘀攀爀Ⰰ 琀栀攀 搀愀琀愀猀琀漀爀攀 挀漀甀氀搀 愀氀猀漀 戀攀 昀漀甀渀搀 漀渀 䰀唀一猀 昀爀漀洀 愀 䘀䌀 匀䄀一 漀爀 椀匀䌀匀䤀 匀䄀一⸀㰀戀爀㸀ഀഀ
਍匀漀Ⰰ 愀 嘀䴀 甀猀攀猀 漀渀攀 漀爀 洀漀爀攀 ∀挀漀洀洀漀渀 搀椀猀欀猀∀Ⰰ 眀栀椀挀栀 愀爀攀 樀甀猀琀 ⸀瘀洀搀欀 昀椀氀攀猀Ⰰ 昀漀爀 攀砀愀洀瀀氀攀 猀琀漀爀攀搀 漀渀 一䘀匀⸀㰀戀爀㸀ഀഀ For a Windows VM, such a disk is the local systemdrive C:, and possible other drives like D:, all stored in their .vmdk files.
਍㰀戀爀㸀ഀഀ However, a VM might also use RDM (Raw Device Mapping). These are LUNs, traditionally stored in an FC SAN,
਍愀渀搀 渀漀眀愀搀愀礀猀 愀氀猀漀 漀昀琀攀渀 漀渀 椀匀䌀匀䤀 匀䄀一猀 琀漀漀⸀㰀戀爀㸀ഀഀ
਍吀栀攀猀攀 刀䐀䴀✀猀 愀爀攀 渀漀琀 琀栀攀 挀漀洀洀漀渀 搀椀猀欀猀 ⠀氀椀欀攀 琀栀攀 猀礀琀攀洀 搀椀猀欀 漀昀 愀 圀椀渀搀漀眀猀 嘀䴀⤀Ⰰ 戀甀琀 愀爀攀 琀栀漀猀攀 猀栀愀爀攀搀 猀琀漀爀愀最攀 愀爀攀愀猀 漀昀琀攀渀 昀漀甀渀搀㰀戀爀㸀ഀഀ in clustered solutions, where for example the SQL Server database files reside on.
਍㰀戀爀㸀ഀഀ ਍㰀䈀㸀䌀漀洀洀漀渀 匀挀攀渀愀爀椀漀㨀㰀戀爀㸀ഀഀ
਍匀漀Ⰰ 愀 挀漀洀洀漀渀 猀挀攀渀愀爀椀漀 椀渀 嘀䴀圀愀爀攀 眀愀猀Ⰰ 琀栀愀琀 琀栀攀 ∀猀礀猀琀攀洀 搀爀椀瘀攀猀∀ 漀昀 琀栀攀 嘀䴀猀 眀攀爀攀 猀琀漀爀攀搀 愀猀 ⸀瘀洀搀欀 昀椀氀攀猀 椀渀 猀漀洀攀 搀愀琀愀猀琀漀爀攀⸀㰀戀爀㸀ഀഀ ਍㰀戀爀㸀ഀഀ For those VMs that needed it, like VMs in an "MSCS/SQL Server cluster", they also used RDMs on a SAN, used for the
਍⠀猀栀愀爀攀搀⤀ 猀琀漀爀愀最攀 漀昀 匀儀䰀 匀攀爀瘀攀爀 搀愀琀愀戀愀猀攀 昀椀氀攀猀Ⰰ 愀渀搀 漀琀栀攀爀 猀栀愀爀攀搀 爀攀猀漀甀爀挀攀猀 渀攀攀搀攀搀 昀漀爀 琀栀攀 挀氀甀猀琀攀爀⸀㰀戀爀㸀ഀഀ
਍吀栀椀猀 椀猀 猀琀椀氀氀 愀 瘀攀爀礀 挀漀洀洀漀渀 猀挀攀渀愀爀椀漀Ⰰ 戀甀琀 椀渀 琀栀攀 氀愀琀攀猀琀 瘀攀爀猀椀漀渀猀Ⰰ 搀椀昀昀攀爀攀渀琀 猀挀攀渀愀爀椀漀✀猀 愀爀攀 瀀漀猀猀椀戀氀攀 琀漀漀⸀㰀戀爀㸀ഀഀ ਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
਍䄀氀琀栀漀甀最栀 愀 嘀䴀圀愀爀攀 栀漀猀琀 挀愀渀 挀漀渀渀攀挀琀 琀漀 瘀愀爀椀漀甀猀 匀䄀一 瘀攀渀搀漀爀猀Ⰰ 椀琀✀猀 樀甀猀琀 愀 昀愀挀琀 琀栀愀琀 ∀一攀琀䄀瀀瀀∀ 匀䄀一猀 愀爀攀 瘀攀爀礀 瀀漀瀀甀氀愀爀⸀㰀戀爀㸀ഀഀ
਍䘀椀最⸀ ㄀㌀⸀ 吀爀愀搀椀琀椀漀渀愀氀 嘀䴀圀愀爀攀 栀漀猀琀猀 愀渀搀 一攀琀䄀瀀瀀 猀琀漀爀愀最攀 猀漀氀甀琀椀漀渀⸀㰀戀爀㸀ഀഀ
਍㰀椀洀最 猀爀挀㴀∀搀椀猀欀搀攀瘀椀挀攀猀㜀⸀樀瀀最∀ 愀氀椀最渀㴀∀挀攀渀琀爀攀∀⼀㸀ഀഀ
਍㰀戀爀㸀ഀഀ In the "sketch" above, we see three VM's, each with their own "virtual machine disk" (vmdk). Such a vmdk disk file
਍挀愀渀 爀攀瀀爀攀猀攀渀琀 琀栀攀椀爀 氀漀挀愀氀 猀礀猀琀攀洀 搀椀猀欀 ⠀氀椀欀攀 䌀㨀 漀渀 愀 圀椀渀搀漀眀猀 嘀䴀⤀⸀㰀戀爀㸀ഀഀ Only the second VM (VM2) uses LUNs from a SAN. In this example, it's a Netapp SAN.
਍ഀഀ
਍一漀眀愀礀搀愀礀猀Ⰰ 昀漀爀 爀攀洀漀琀攀 䠀漀猀琀猀 ⠀氀椀欀攀 愀渀 䔀匀堀椀 栀漀猀琀⤀ 琀漀 挀漀渀渀攀挀琀 琀漀 愀 匀䄀一Ⰰ 渀漀琀 漀渀氀礀 䘀椀戀爀攀 䌀栀愀渀渀攀氀 ⠀䘀䌀⤀ 椀猀 甀猀攀搀Ⰰ㰀戀爀㸀ഀഀ but iSCSI and various forms of NFS/NAS implementations have gained popularity too.
਍㰀戀爀㸀ഀഀ
਍㰀栀㐀㸀䐀椀猀欀猀 椀渀 嘀䴀圀愀爀攀㨀㰀⼀栀㐀㸀㰀戀爀㸀ഀഀ ਍㰀䈀㸀☀⌀㠀㘀㔀㠀㬀 嘀䴀䐀䬀 昀椀氀攀猀 ⠀猀礀猀琀攀洀 搀椀猀欀 愀渀搀 漀瀀琀椀漀渀愀氀氀礀 漀琀栀攀爀 搀椀猀欀猀 漀昀 琀栀攀 嘀䴀⤀㨀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
਍䄀 猀愀椀搀 戀攀昀漀爀攀Ⰰ 嘀䴀✀猀 甀猀攀猀 ∀⸀瘀洀搀欀∀ 昀椀氀攀猀 昀漀爀 琀栀攀椀爀 猀礀猀琀攀洀搀椀猀欀Ⰰ 愀渀搀 漀瀀琀椀漀渀愀氀氀礀 漀琀栀攀爀 搀椀猀欀猀⸀㰀戀爀㸀ഀഀ Ofcourse, such a VM might additionally also use a LUN from an FC SAN, or iSCSI SAN, or other LUN provider.
਍㰀戀爀㸀ഀഀ Let's first see how the VM's systemdisks (their .vmdk file and other files) are organized.
਍㰀戀爀㸀ഀഀ Note: The sample commands below, are just part of a full procedure, and cannot be used isolated.
਍吀栀攀礀 愀爀攀 氀椀猀琀攀搀 昀漀爀 椀氀氀甀猀琀爀愀琀椀漀渀愀氀 瀀甀爀瀀漀猀攀猀 漀渀氀礀⸀㰀戀爀㸀ഀഀ
਍嘀䴀圀愀爀攀 甀猀攀猀 琀栀攀 挀漀渀挀攀瀀琀 漀昀 ∀搀愀琀愀猀琀漀爀攀∀Ⰰ 眀栀椀挀栀 挀愀渀 戀攀 瘀椀攀眀搀 愀猀 愀 ∀猀琀漀爀愀最攀 挀漀渀琀愀椀渀攀爀∀ 昀漀爀 昀椀氀攀猀⸀㰀戀爀㸀ഀഀ The datastore could be on a local Host hard drive, on NFS, or (nowadays) even on a FC or iSCSI SAN.
਍∀䤀渀猀椀搀攀∀ 琀栀攀 搀愀琀愀猀琀漀爀攀Ⰰ 礀漀甀 眀椀氀氀 昀椀渀搀 琀栀攀 瘀椀爀琀甀愀氀 洀愀挀栀椀渀攀猀 ⸀瘀洀搀欀 昀椀氀攀猀 愀渀搀 漀琀栀攀爀 昀椀氀攀猀 ⠀氀椀欀攀 愀 ⸀瘀洀砀 挀漀渀昀椀最昀椀氀攀⤀⸀㰀戀爀㸀ഀഀ Here, our aim is to find out which files makes up a VM's systemdisk. But, let's first create a datastore.
਍㰀戀爀㸀ഀഀ You can use graphical tools to create a new datastore (like vSphere client), or you can use a commandline.
਍䤀渀 嘀䴀圀愀爀攀Ⰰ 甀猀椀渀最 最爀愀瀀栀椀挀愀氀 琀漀漀氀猀 眀栀椀氀攀 挀漀渀渀攀挀琀攀搀 琀漀 愀 挀攀渀琀爀愀氀 䴀愀渀愀最攀洀攀渀琀 匀攀爀瘀攀爀Ⰰ 椀猀 琀栀攀 戀攀猀琀 眀愀礀 琀漀 最漀⸀㰀戀爀㸀ഀഀ
਍䠀漀眀攀瘀攀爀Ⰰ 昀漀爀 椀氀氀甀猀琀爀愀琀椀漀渀愀氀 瀀甀爀瀀漀猀攀猀Ⰰ 愀 琀礀瀀椀挀愀氀 挀漀洀洀愀渀搀 琀漀 挀爀攀愀琀攀 愀 搀愀琀愀猀琀漀爀攀 氀漀挀愀氀氀礀 漀渀 愀 䔀匀堀椀 栀漀猀琀Ⰰ㰀戀爀㸀ഀഀ while having a session to that host, looks similar to this:
਍㰀戀爀㸀ഀഀ ਍ഀഀ # vmkfstools -C vmfs5 -b 8m -S Datastore2 /vmfs/devices/disks/naa.60811234567899155456789012345321:1
਍ഀഀ ਍㰀戀爀㸀ഀഀ Now, lets suppose that we already have created several VM's. How does the VM files "look like"?
਍䠀攀爀攀 琀漀漀Ⰰ 愀猀 愀 瀀爀攀氀椀洀椀渀愀爀礀Ⰰ 椀琀 椀猀 椀洀瀀漀爀琀愀渀琀 琀栀愀琀 琀栀攀 嘀䴀✀猀 眀攀爀攀 瀀爀漀瀀攀爀氀礀 爀攀最椀猀琀攀爀攀搀 椀渀 琀栀攀 爀攀瀀漀猀椀琀漀爀礀 漀昀 ∀瘀䌀攀渀琀攀爀∀ ⠀漀爀 ∀嘀椀爀琀甀愀氀䌀攀渀琀攀爀∀⤀⸀㰀戀爀㸀ഀഀ Again, using the vSphere client, those actions are really easy and it makes sure the VM's are properly registered.
਍䠀攀爀攀Ⰰ 樀甀猀琀 ∀戀爀漀眀猀攀∀ 琀栀攀 挀漀爀爀攀挀琀 搀愀琀愀猀琀漀爀攀Ⰰ 氀漀挀愀琀攀 琀栀攀 挀漀爀爀攀挀琀 ⸀瘀洀砀 昀椀氀攀Ⰰ 愀渀搀 挀栀漀漀猀攀 ∀爀攀最椀猀琀攀爀∀⸀ 嘀攀爀礀 攀愀猀礀 椀渀搀攀攀搀⸀㰀戀爀㸀ഀഀ
਍䘀漀爀 椀氀氀甀猀琀爀愀琀椀漀渀愀氀 瀀甀爀瀀漀猀攀猀Ⰰ 椀昀 栀愀瘀椀渀最 愀 猀攀猀猀椀漀渀 琀漀 愀渀 䔀匀堀椀 䠀漀猀琀Ⰰ 愀 挀漀洀洀愀渀搀氀椀渀攀 愀挀琀椀漀渀 洀椀最栀琀 爀攀猀攀洀戀氀攀 琀栀椀猀㨀㰀戀爀㸀ഀഀ
਍㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀甀攀∀㸀ഀഀ ਍⌀ 瘀椀洀ⴀ挀洀搀 ⴀ猀 爀攀最椀猀琀攀爀 ⼀瘀洀昀猀⼀瘀漀氀甀洀攀猀⼀搀愀琀愀猀琀漀爀攀㈀⼀瘀洀㄀⼀嘀䴀㄀⸀瘀洀砀㰀戀爀㸀ഀഀ ਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
਍夀漀甀 洀椀最栀琀 猀愀礀 琀栀愀琀 琀栀攀 嘀䴀 ∀攀砀椀猀琀猀∀Ⰰ 眀栀攀渀 椀琀 眀愀猀 猀栀甀琀搀漀眀渀Ⰰ 猀漀氀攀氀礀 漀昀 琀栀攀 昀椀氀攀猀 氀漀挀愀琀攀搀 椀渀 琀栀攀 搀愀琀愀猀琀漀爀攀⸀㰀戀爀㸀ഀഀ The files can be found in the VM's "homedirectory".
਍㰀戀爀㸀ഀഀ Actually, there are a number of files, with different extensions, and different purposes.
਍匀甀瀀瀀漀猀攀 琀栀愀琀 漀甀爀 嘀䴀 椀猀 渀愀洀攀搀 ∀嘀䴀㄀∀Ⰰ 琀栀攀渀 栀攀爀攀 椀猀 愀 琀礀瀀椀挀愀氀 氀椀猀琀椀渀最 漀昀 琀栀攀 洀漀猀琀 瀀爀漀洀椀渀攀渀琀 昀椀氀攀猀㨀㰀戀爀㸀ഀഀ ਍㰀戀爀㸀ഀഀ Fig.12: Some files that make up a VM in VMWare.
਍ഀഀ ਍㰀戀爀㸀ഀഀ ਍ ഀഀ ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀瘀洀㄀⸀渀瘀爀愀洀㰀⼀吀䐀㸀ഀഀ ਍㰀⼀吀刀㸀ഀഀ ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀瘀洀㄀⸀瘀洀砀㰀⼀吀䐀㸀ഀഀ ਍㰀吀刀㸀ഀഀ ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀吀栀攀 昀甀氀氀 挀漀渀琀攀渀琀 漀昀 琀栀攀 嘀䴀✀猀 ∀栀愀爀搀搀椀猀欀∀⸀㰀⼀吀䐀㸀ഀഀ ਍㰀吀刀㸀ഀഀ ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀匀眀愀瀀昀椀氀攀 愀猀猀漀挀椀愀琀攀搀 眀椀琀栀 琀栀椀猀 嘀䴀⸀㰀⼀吀䐀㸀ഀഀ ਍㰀吀刀㸀ഀഀ ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀䤀昀 琀栀攀 嘀䴀 甀猀攀猀 匀䄀一 䰀唀一猀Ⰰ 琀栀椀猀 椀猀 愀 瀀爀漀砀礀 ⸀瘀洀搀欀 昀漀爀 愀 刀䄀圀 䰀甀渀⸀㰀⼀吀䐀㸀ഀഀ ਍㰀吀刀㸀ഀഀ ਍ 㰀吀䐀㸀㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀㸀嘀愀爀椀漀甀猀 氀漀最 昀椀氀攀猀 攀砀椀猀琀猀 昀漀爀 嘀䴀 愀挀琀椀瘀椀琀礀 爀攀挀漀爀搀猀Ⰰ 甀猀愀戀氀攀 昀漀爀 琀爀漀甀戀氀攀猀栀漀漀琀椀渀最⸀㰀戀爀㸀ഀഀ The current one is called vmware.log, and a number of former log files are retained. ਍㰀⼀吀刀㸀ഀഀ

The "firmware" or "BIOS" as presented to the VM by the Host.

Editable configuration file with specific setting for this VM ਍                                 氀椀欀攀 愀洀漀甀渀琀 漀昀 刀䄀䴀Ⰰ 渀椀挀 椀渀昀漀Ⰰ 搀椀猀欀 椀渀昀漀 攀琀挀⸀⸀㰀⼀吀䐀㸀ഀഀ

vm1-flat.vmdk

vm1.vswp

-rdm.vmdk

.log files

਍㰀戀爀㸀ഀഀ ਍ഀഀ This list is far from complete, but it's enough for getting an idea about how it's organized.
਍ഀഀ
਍㰀戀爀㸀ഀഀ
਍ഀഀ ਍㰀栀爀⼀㸀ഀഀ

Chapter 8. A FEW NOTES ON NETAPP.

਍㰀栀爀⼀㸀ഀഀ ਍ഀഀ ਍㰀栀㌀㸀㠀⸀㄀ 䄀 焀甀椀挀欀 漀瘀攀爀瘀椀攀眀⸀㰀⼀栀㌀㸀ഀഀ ਍ഀഀ NetApp is the name of a company, delivering a range of small to large popular SAN solutions.
਍㰀戀爀㸀ഀഀ It's not really possible to "capture" the solution in just a few pages. People go to trainings for a good reason:
਍琀栀攀 瀀爀漀搀甀挀琀 椀猀 瘀攀爀礀 眀椀搀攀Ⰰ 愀渀搀 琀攀挀栀渀椀挀愀氀氀礀 挀漀洀瀀氀攀砀⸀ 吀漀 椀洀瀀氀攀洀攀渀琀 愀渀 漀瀀琀椀洀愀氀 挀漀渀昀椀最甀爀攀搀 匀䄀一Ⰰ 椀猀 愀 爀攀愀氀 挀栀愀氀氀攀渀最攀⸀㰀戀爀㸀ഀഀ So, this chapter does not even scratch the surface, I am afraid. However, to get a high-level impression, it should be OK.
਍ഀഀ ਍㰀戀爀㸀ഀഀ Essentially, a high-level description of "NetApp" is like this:
਍㰀甀氀㸀ഀഀ

A controller, called the "Filer" or "FAS" (NetApp Fabric-Attached Storage), functions as the managing device for the SAN.

਍㰀氀椀㸀吀栀攀 䘀椀氀攀爀 爀甀渀猀 琀栀攀 ∀伀渀琀愀瀀∀ 伀瀀攀爀愀琀椀渀最 匀礀猀琀攀洀Ⰰ 愀 甀渀椀砀ⴀ氀椀欀攀 猀礀猀琀攀洀Ⰰ 眀栀椀挀栀 栀愀猀 椀琀✀猀 爀漀漀琀 椀渀 䘀爀攀攀䈀匀䐀⸀㰀⼀氀椀㸀ഀഀ

The Filer manages "diskarrys" which are also called "shelves".

਍㰀氀椀㸀䤀琀 甀猀攀猀 愀 ∀甀渀椀昀椀攀搀∀ 愀爀挀栀椀琀攀挀琀甀爀攀Ⰰ 琀栀愀琀 椀猀Ⰰ 昀爀漀洀 猀洀愀氀氀 琀漀 氀愀爀最攀 匀䄀一猀Ⰰ 椀琀✀猀 琀栀攀 猀愀洀攀 伀渀琀愀瀀 猀漀昀琀眀愀爀攀Ⰰ 眀椀琀栀 琀栀攀㰀戀爀㸀ഀഀ same CL and tools, and methodology. ਍㰀氀椀㸀䴀愀渀礀 昀攀愀琀甀爀攀猀 椀渀 一攀琀䄀瀀瀀⼀伀渀琀愀瀀 洀甀猀琀 戀攀 猀攀瀀攀爀愀琀攀氀礀 氀椀挀攀渀猀攀搀Ⰰ 愀渀搀 琀栀攀 氀椀猀琀 漀昀 昀攀愀琀甀爀攀猀 椀猀 瘀攀爀礀 椀洀瀀爀攀猀猀椀瘀攀⸀㰀⼀氀椀㸀ഀഀ

There is a range of SNAP* methodologies which allows for very fast backups, and replication of Storage data to other another controller and its shelves,
਍愀渀搀 洀甀挀栀 洀漀爀攀 漀琀栀攀爀 猀琀甀昀昀Ⰰ 渀漀琀 洀攀渀琀椀漀渀攀搀 栀攀爀攀⸀ 䈀甀琀 眀攀 眀椀氀氀 搀椀猀挀甀猀猀 匀渀愀瀀猀栀漀琀 戀愀挀欀甀瀀 吀攀挀栀渀漀氀漀最礀 椀渀 猀攀挀琀椀漀渀 㠀⸀㐀⸀㰀⼀氀椀㸀ഀഀ

The storage itself uses the WAFL filesystem, which is more than just a "filesystem". It was probably inspired by "FFS/Episode/LFS",
਍爀攀猀甀氀琀椀渀最 椀渀 ∀愀 猀漀爀琀 漀昀∀ 䘀椀氀攀猀礀猀琀攀洀 眀椀琀栀 ∀瘀攀爀礀∀ 攀砀琀攀渀搀攀搀 䰀嘀䴀 挀愀瀀愀戀椀氀椀琀椀攀猀⸀㰀戀爀㸀ഀഀ ਍㰀戀爀㸀ഀഀ Fig. 14. SAN: Very simplified view on connection of the NetApp Filer (controller) to diskshelves.
਍㰀戀爀㸀ഀഀ ਍㰀戀爀㸀ഀഀ
਍䤀渀 琀栀攀 ∀猀欀攀琀挀栀∀ 愀戀漀瘀攀Ⰰ 眀攀 猀攀攀 愀 猀椀洀瀀氀椀昀椀攀搀 洀漀搀攀氀 漀昀 愀 一攀琀䄀瀀瀀 匀䄀一⸀㰀戀爀㸀 ഀഀ Here, the socalled "Filer", or the "controller" (or "FAS"), is connected to two disk shelves (disk arrays).
਍䴀漀猀琀 匀䄀一猀Ⰰ 氀椀欀攀 一攀琀䄀瀀瀀Ⰰ 猀甀瀀瀀漀爀琀猀 䘀䌀倀 搀椀猀欀猀Ⰰ 匀䄀匀 搀椀猀欀猀Ⰰ 愀渀搀 ⠀猀氀漀眀攀爀⤀ 匀䄀吀䄀 搀椀猀欀猀⸀㰀戀爀㸀ഀഀ Since quite some time, NetApp favoures to put SAS disks in their shelves.
਍㰀戀爀㸀ഀഀ If the Storage Admin wants, he or she can configure the system to act as a SAN and/or as a NAS, so that it can provide storage using either
਍昀椀氀攀ⴀ戀愀猀攀搀 漀爀 戀氀漀挀欀ⴀ戀愀猀攀搀 瀀爀漀琀漀挀漀氀猀⸀㰀戀爀㸀ഀഀ
਍吀栀攀 瀀椀挀琀甀爀攀 愀戀漀瘀攀 椀猀 攀砀琀爀攀洀攀氀礀 猀椀洀瀀氀攀⸀ 伀昀琀攀渀Ⰰ 琀眀漀 䘀椀氀攀爀猀 愀爀攀 愀爀爀愀渀最攀渀搀 椀渀 愀 挀氀甀猀琀攀爀攀搀 猀漀氀甀琀椀漀渀Ⰰ 眀椀琀栀 洀甀氀琀椀瀀氀攀 瀀愀琀栀猀㰀戀爀㸀ഀഀ to multiple diskshelves. This would then be a HA solution using a "Failover" methodology.
਍匀漀Ⰰ 猀甀瀀瀀漀猀攀 ∀渀攀琀愀瀀瀀㄀∀ 愀渀搀 ∀渀攀琀愀瀀瀀㈀∀ 愀爀攀 琀眀漀 䘀椀氀攀爀猀Ⰰ 攀愀挀栀 挀漀渀琀爀漀氀氀椀渀最 琀栀攀椀爀 漀眀渀 猀栀攀氀瘀攀猀⸀ 吀栀攀渀 椀昀 渀攀琀愀瀀瀀㄀ 眀漀甀氀搀 昀愀椀氀 昀漀爀 猀漀洀攀 爀攀愀猀漀渀Ⰰ㰀戀爀㸀ഀഀ the ownership of its shelves would go to the netapp2 filer.
਍㰀戀爀㸀ഀഀ
਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀爀攀搀∀㸀ഀഀ ਍㰀栀㌀㸀㠀⸀㈀ 䄀 挀漀渀挀攀瀀琀甀愀氀 瘀椀攀眀 漀渀 一攀琀䄀瀀瀀 匀琀漀爀愀最攀⸀㰀⼀栀㌀㸀ഀഀ ਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ ਍一漀琀攀 昀爀漀洀 昀椀最甀爀攀 ㄀㐀Ⰰ 琀栀愀琀 椀昀 愀 猀栀攀氀瘀攀 椀猀 漀渀 瀀漀爀琀 ∀　愀∀Ⰰ 琀栀攀 伀渀琀愀瀀 猀漀昀琀眀愀爀攀 椀搀攀渀琀椀昀椀攀猀 椀渀搀椀瘀椀搀甀愀氀 搀椀猀欀猀 戀礀 琀栀攀 瀀漀爀琀渀甀洀戀攀爀 愀渀搀 琀栀攀 搀椀猀欀✀猀 匀䌀匀䤀 䤀䐀Ⰰഀഀ like for example "0a.10", "0a.11", "0a.12" etc..
਍㰀戀爀㸀ഀഀ ਍㰀戀爀㸀ഀഀ This sort of identifiers are used in many Ontap prompt (CL) commands.
਍㰀戀爀㸀ഀഀ But first it's very important to get a notion on how NetApp organizes it's storage. Here we will show a very high-level
਍挀漀渀挀攀瀀琀甀愀氀 洀漀搀攀氀⸀㰀戀爀㸀ഀഀ
਍䘀椀最⸀ ㄀㔀⸀ 一攀琀䄀瀀瀀✀猀 漀爀最愀渀椀稀愀琀椀漀渀 漀昀 匀琀漀爀愀最攀⸀㰀戀爀㸀ഀഀ
਍㰀椀洀最 猀爀挀㴀∀搀椀猀欀搀攀瘀椀挀攀猀㄀㈀⸀樀瀀最∀ 愀氀椀最渀㴀∀挀攀渀琀爀攀∀⼀㸀ഀഀ
਍㰀戀爀㸀ഀഀ The most fundamental level is the "Raid Group" (RG). NetApp uses "RAID4", or "RAID6 with double parity (DP)" on two disks,
਍眀栀椀挀栀 椀猀 琀栀攀 洀漀猀琀 爀漀戀甀猀琀 漀瀀琀椀漀渀 漀昀挀漀甀爀猀攀⸀ 䤀琀✀猀 瀀漀猀猀椀戀氀攀 琀漀 栀愀瘀攀 漀渀攀 漀爀 洀漀爀攀 刀愀椀搀 䜀爀漀甀瀀猀⸀㰀戀爀㸀ഀഀ
਍䄀渀 㰀䈀㸀∀䄀最最爀攀最愀琀攀∀㰀⼀䈀㸀 椀猀 愀 氀漀最椀挀愀氀 攀渀琀椀琀礀Ⰰ 挀漀洀瀀漀猀攀搀 漀昀 漀渀攀 漀爀 洀漀爀攀 刀愀椀搀 䜀爀漀甀瀀猀⸀㰀戀爀㸀ഀഀ Once created, it fundamentally represents the storage unit.
਍㰀戀爀㸀ഀഀ If you want, you might say that an aggregate "sort of" virtualizes the real physical implementation of RG's
਍㰀戀爀㸀ഀഀ Ontap will create RG groups for you "behind the scene" when you create an aggregate. It uses certain rules for this,
਍搀攀瀀攀渀搀椀渀最 漀渀 搀椀猀欀 琀礀瀀攀Ⰰ 搀椀猀欀 挀愀瀀愀挀椀琀椀攀猀 愀渀搀 琀栀攀 渀甀洀戀攀爀 漀昀 搀椀猀欀猀 挀栀漀漀猀攀渀 昀漀爀 琀栀攀 愀最最爀攀最愀琀攀⸀ 匀漀Ⰰ 礀漀甀 挀漀甀氀搀 攀渀搀 甀瀀 眀椀琀栀 漀渀攀 漀爀 洀漀爀攀 刀䜀✀猀㰀戀爀㸀ഀഀ when creating a certain aggregate.
਍㰀戀爀㸀ഀഀ As an example, for a certain default setup:
਍㰀戀爀㸀ഀഀ - if you would create a 16 disk aggregate, you would end up with one RG.
਍ⴀ 椀昀 礀漀甀 眀漀甀氀搀 挀爀攀愀琀攀 愀 ㌀㈀ 搀椀猀欀 愀最最爀攀最愀琀攀Ⰰ 礀漀甀 眀漀甀氀搀 攀渀搀 甀瀀 眀椀琀栀 琀眀漀 刀䜀✀猀⸀㰀戀爀㸀  ഀഀ
਍䤀琀✀猀 焀甀椀琀攀 愀渀 愀爀琀 琀漀 最攀琀 琀栀攀 愀爀椀琀栀洀攀琀椀挀 爀椀最栀琀⸀ 䠀漀眀 氀愀爀最攀 搀漀 礀漀甀 挀爀攀愀琀攀 愀渀 愀最最爀攀最愀琀攀 椀渀椀琀椀愀氀氀礀㼀 圀栀愀琀 栀愀瀀瀀攀渀猀 椀昀 愀搀搀椀琀椀漀渀愀氀 猀瀀椀渀搀氀攀猀㰀戀爀㸀ഀഀ become available later? Can you then still expand the aggregate? What is the ratio of usable space compared to what gets reserved?
਍㰀戀爀㸀ഀഀ You see? When architecting these structures, you need a lot of detailed knowledge and do a large amount of planning.
਍㰀戀爀㸀ഀഀ A FlexVol is next level of storage, "carved out" from the aggregate. The FlexVol forms the basis for "real" usable stuff, like
਍䰀唀一猀 ⠀昀漀爀 䘀䌀 漀爀 椀匀䌀匀䤀⤀Ⰰ 漀爀 䌀䤀䘀匀⼀一䘀匀 猀栀愀爀攀猀⸀㰀戀爀㸀ഀഀ
਍䘀爀漀洀 愀 䘀氀攀砀嘀漀氀Ⰰ 䌀䤀䘀匀⼀一䘀匀 猀栀愀爀攀猀 漀爀 䰀唀一猀 愀爀攀 挀爀攀愀琀攀搀⸀㰀戀爀㸀ഀഀ
਍䄀 䰀唀一 椀猀 愀 氀漀最椀挀愀氀 爀攀瀀爀攀猀攀渀琀愀琀椀漀渀 漀昀 猀琀漀爀愀最攀⸀ 䄀猀 眀攀 栀愀瘀攀 猀攀攀渀 戀攀昀漀爀攀Ⰰ 椀琀 ∀樀甀猀琀 氀漀漀欀猀∀ 氀椀欀攀 愀 栀愀爀搀 搀椀猀欀 琀漀 琀栀攀 挀氀椀攀渀琀⸀㰀戀爀㸀ഀഀ From a NetApp perspective, it looks like a file inside a volume.
਍吀栀攀 琀爀甀攀 瀀栀礀猀椀挀愀氀 椀洀瀀氀攀洀攀渀琀愀琀椀漀渀 漀昀 愀 䰀唀一 漀渀 琀栀攀 愀最最爀攀最愀琀攀Ⰰ 椀猀 琀栀愀琀 椀琀 椀猀 愀 ∀猀琀爀椀瀀攀∀ 漀瘀攀爀 一 瀀栀礀猀椀挀愀氀 搀椀猀欀猀 椀渀 刀䄀䤀䐀 䐀倀⸀㰀戀爀㸀ഀഀ
਍圀栀礀 眀漀甀氀搀 礀漀甀 挀栀漀漀猀攀 䌀䤀䘀匀⼀一䘀匀 漀爀 ⠀䘀䌀⼀椀匀䌀匀䤀⤀ 䰀唀一猀㼀 䐀攀瀀攀渀搀猀 漀渀 琀栀攀 愀瀀瀀氀椀挀愀琀椀漀渀⸀ 䤀昀 礀漀甀 渀攀攀搀 愀 氀愀爀最攀 猀栀愀爀攀Ⰰ 琀栀攀渀 琀栀攀 愀渀猀眀攀爀 椀猀 漀戀瘀椀漀甀猀⸀㰀戀爀㸀ഀഀ Also, some Hosts really need storage that acts like a local disk, and where SCSI reservations can be placed on (as in clustering).
਍䤀渀 琀栀椀猀 挀愀猀攀Ⰰ 礀漀甀 漀戀瘀椀漀甀猀氀礀 渀攀攀搀 琀漀 挀爀攀愀琀攀 愀 䰀唀一⸀㰀戀爀㸀ഀഀ
਍匀椀渀挀攀Ⰰ 甀猀椀渀最 一攀琀䄀瀀瀀 琀漀漀氀猀Ⰰ 䰀唀一猀 愀爀攀 猀漀洀攀琀椀洀攀猀 爀攀瀀爀攀猀攀渀琀攀搀 ⠀漀爀 猀栀漀眀攀搀⤀ 愀猀 ∀昀椀氀攀猀∀Ⰰ 琀栀攀 攀渀琀椀琀礀 ∀焀琀爀攀攀∀ 最攀琀猀 洀攀愀渀椀渀最 琀漀漀⸀㰀戀爀㸀ഀഀ It's analogous to a folder/subdirectory. So, it's possible to "associate" LUNs with a qtree.
਍匀椀渀挀攀 椀琀 栀愀瘀攀 琀栀攀 瀀爀漀瀀攀爀琀椀攀猀 琀栀愀琀 愀 昀漀氀搀攀爀 栀愀猀 琀漀漀Ⰰ 礀漀甀 挀愀渀 愀猀猀漀挀椀愀琀攀 一吀䘀匀 漀爀 唀渀椀砀ⴀ氀椀欀攀 瀀攀爀洀椀猀猀椀漀渀猀 琀漀 愀氀氀㰀戀爀㸀ഀഀ objects associated to that qtree.
਍㰀戀爀㸀ഀഀ
਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀爀攀搀∀㸀ഀഀ ਍㰀栀㌀㸀㠀⸀㌀ 䄀 渀漀琀攀 漀渀 琀漀漀氀猀⸀㰀⼀栀㌀㸀ഀഀ ਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ ਍吀栀攀爀攀 愀爀攀 愀 昀攀眀 瘀攀爀礀 椀洀瀀漀爀琀愀渀琀 㰀䈀㸀䜀唀䤀 漀爀 圀攀戀戀愀猀攀搀 琀漀漀氀猀㰀⼀䈀㸀 昀漀爀 愀 匀琀漀爀愀最攀 䄀搀洀椀渀Ⰰ 昀漀爀 挀漀渀昀椀最甀爀椀渀最 愀渀搀 洀漀渀椀琀漀爀椀渀最 琀栀攀椀爀 䘀椀氀攀爀猀 愀渀搀 匀琀漀爀愀最攀⸀㰀戀爀㸀ഀഀ Once "FilerView" (depreciated on Ontap 8) was great, and followup versions like "OnCommand System Manager" are probably indispensable too.
਍㰀戀爀㸀ഀഀ These type of GUI tools allow for monitoring, and creating/modifying all entities as discussed in section 8.2.
਍㰀戀爀㸀ഀഀ It's also possible to setup a "ssh" session through a network to the Filer, and it also has a serial "console" port for direct communication.
਍㰀戀爀㸀ഀഀ
਍吀栀攀爀攀 椀猀 愀 瘀攀爀礀 猀琀爀漀渀最 ∀挀漀洀洀愀渀搀 氀椀渀攀∀ ⠀䌀䰀⤀ 愀瘀愀椀氀愀戀氀攀 琀漀漀Ⰰ 眀栀椀挀栀 栀愀猀 愀 爀攀猀瀀攀挀琀愀戀氀攀 ∀氀攀愀爀渀椀渀最 挀甀爀瘀攀∀⸀㰀戀爀㸀ഀഀ
਍䔀瘀攀渀 椀昀 礀漀甀 栀愀瘀攀 愀 瘀攀爀礀 猀琀爀漀渀最 戀愀挀欀最爀漀甀渀搀 椀渀 䤀吀Ⰰ 渀漀琀栀椀渀最 椀渀 栀愀渀搀氀椀渀最 愀 匀䄀一 漀昀 愀 猀瀀攀挀椀昀椀挀 嘀攀渀搀漀爀 椀猀 ∀攀愀猀礀∀⸀㰀戀爀㸀ഀഀ Since, if a SAN is in full production, almost all vital data of your Organization is centered on the SAN, you cannot afford any mistakes.
਍吀漀 戀攀 挀愀爀攀昀甀氀氀 愀渀搀 渀漀琀 琀愀欀椀渀最 愀渀礀 爀椀猀欀猀Ⰰ 椀猀 愀 最漀漀搀 焀甀愀氀椀琀礀⸀㰀戀爀㸀ഀഀ
਍吀栀攀爀攀 愀爀攀 栀甀渀搀爀攀搀猀 漀昀 挀漀洀洀愀渀搀猀⸀ 匀漀洀攀 愀爀攀 ∀瀀甀爀攀∀ 甀渀椀砀 猀栀攀氀氀ⴀ氀椀欀攀Ⰰ 氀椀欀攀 ∀搀昀∀ 愀渀搀 洀愀渀礀 漀琀栀攀爀猀⸀ 䈀甀琀 洀漀猀琀 愀爀攀 猀瀀攀挀椀昀椀挀 琀漀 伀渀琀愀瀀 氀椀欀攀 ∀愀最最爀 挀爀攀愀琀攀∀㰀戀爀㸀ഀഀ and many others to create and modify the entities as discussed in section 8.2.
਍㰀戀爀㸀ഀഀ If you want to be "impressed", here are some links to "Ontap CL" references:
਍㰀戀爀㸀ഀഀ Ontap 7.x mode CL Reference
਍㰀愀 栀爀攀昀㴀∀栀琀琀瀀㨀⼀⼀挀漀渀琀漀甀爀搀猀⸀挀漀洀⼀甀瀀氀漀愀搀猀⼀昀椀氀攀⼀一攀琀愀瀀瀀开刀攀猀漀甀爀挀攀䌀攀渀琀攀爀㈀⸀瀀搀昀∀㸀伀渀琀愀瀀 㠀⸀砀 洀漀搀攀 䌀䰀 刀攀昀攀爀攀渀挀攀㰀⼀愀㸀㰀戀爀㸀ഀഀ
਍㰀戀爀㸀ഀഀ ਍ഀഀ

8.4 A note on SNAPSHOT Backup Technology.

਍ഀഀ ਍ഀഀ One attractive feature of NetApps storage, is the range of SNAP technologies, like the usage of SNAPSHOT backups.
਍夀漀甀 挀愀渀✀琀 琀愀氀欀 愀戀漀甀琀 一攀琀䄀瀀瀀Ⰰ 愀渀搀 渀漀琀 搀攀愀氀椀渀最 眀椀琀栀 琀栀椀猀 漀渀攀⸀㰀戀爀㸀ഀഀ
਍䘀爀漀洀 刀愀椀搀 䜀爀漀甀瀀猀Ⰰ 愀渀 愀最最爀攀最愀琀攀 椀猀 挀爀攀愀琀攀搀⸀ 䘀爀漀洀 愀渀 愀最最爀攀最愀琀攀Ⰰ 䘀氀攀砀嘀漀氀猀 愀爀攀 挀爀攀愀琀攀搀⸀ 䘀爀漀洀 愀 䘀氀攀砀嘀漀氀Ⰰ 愀 一䄀匀 ⠀猀栀愀爀攀⤀ 洀椀最栀琀 戀攀 挀爀攀愀琀攀搀Ⰰ㰀戀爀㸀ഀഀ or LUNs might be created (accesible via FCP/iSCSI).
਍㰀戀爀㸀ഀഀ Now, we know that NetApp uses the WAFL "filesystem", and it has its own "overhead", which will diminish your total usable space.
਍吀栀椀猀 漀瘀攀爀栀攀愀搀 椀猀 攀猀琀椀洀愀琀攀搀 琀漀 戀攀 愀戀漀甀琀 ㄀　─ 瀀攀爀 搀椀猀欀 ⠀渀漀琀 爀攀挀氀愀椀洀愀戀氀攀⤀⸀ 䤀琀✀猀 瀀愀爀琀氀礀 甀猀攀搀 昀漀爀 㰀䈀㸀圀䄀䘀䰀 洀攀琀愀搀愀琀愀㰀⼀䈀㸀⸀㰀戀爀㸀ഀഀ
਍䄀瀀愀爀琀 昀爀漀洀 ∀漀瘀攀爀栀攀愀搀∀Ⰰ 猀攀瘀攀爀愀氀 愀搀搀椀琀椀漀渀愀氀 㰀䈀㸀∀爀攀猀攀爀瘀愀琀椀漀渀猀∀㰀⼀䈀㸀愀爀攀 椀渀 攀昀昀攀挀琀⸀㰀戀爀㸀ഀഀ
਍圀栀攀渀 愀渀 愀最最爀攀最愀琀攀 椀猀 挀爀攀愀琀攀搀Ⰰ 瀀攀爀 搀攀昀愀甀氀琀 ∀爀攀猀攀爀瘀攀搀 猀瀀愀挀攀∀ 椀猀 搀攀昀椀渀攀搀 琀漀 栀漀氀搀 漀瀀琀椀漀渀愀氀 昀甀琀甀爀攀 ∀猀渀愀瀀猀栀漀琀∀ 挀漀瀀椀攀猀⸀㰀戀爀㸀ഀഀ The Storage Admin has a certain degree of freedom of the size of this reserved space, but in general it is advised
਍渀漀琀 琀漀 猀攀琀 椀琀 琀漀漀 氀漀眀⸀ 䄀猀 愀 最甀椀搀攀氀椀渀攀 ⠀愀渀搀 搀攀昀愀甀氀琀⤀Ⰰ 漀昀琀攀渀 愀 瘀愀氀甀攀 漀昀 㔀─ 椀猀 ∀瀀漀猀琀甀氀愀琀攀搀∀⸀㰀戀爀㸀ഀഀ
਍一攀砀琀Ⰰ 椀琀✀猀 瀀漀猀猀椀戀氀攀 琀漀 挀爀攀愀琀攀 愀 ∀猀渀愀瀀猀栀漀琀 爀攀猀攀爀瘀攀∀ 昀漀爀 愀 䘀氀攀砀嘀漀氀 琀漀漀⸀㰀戀爀㸀ഀഀ Here the Storage Admin has a certain degree of freedom as well. NetApp generally seems to indicate that a snapshot
਍爀攀猀攀爀瘀攀 漀昀 ㈀　─ 猀栀漀甀氀搀 戀攀 愀瀀瀀氀椀攀搀⸀ 䠀漀眀攀瘀攀爀Ⰰ 渀甀洀戀攀爀猀 猀攀攀洀 琀漀 瘀愀爀礀 猀漀洀攀眀栀愀琀 眀栀攀渀 爀攀愀搀椀渀最 瘀愀爀椀漀甀猀 爀攀挀漀洀洀攀渀搀愀琀椀漀渀猀⸀㰀戀爀㸀ഀഀ However, there is a big difference in NAS and SAN LUN based Volumes.
਍㰀戀爀㸀ഀഀ Here is an example of manipulating the reserved space on the volume level, setting it to 15%, using the Ontap CL:
਍㰀戀爀㸀ഀഀ ਍䘀䄀匀㄀㸀 猀渀愀瀀 爀攀猀攀爀瘀攀 瘀漀氀㄀　 ㄀㔀 㰀戀爀㸀ഀഀ ਍㰀戀爀㸀ഀഀ
਍㰀䈀㸀㰀唀㸀匀渀愀瀀猀栀漀琀 吀攀挀栀渀漀氀漀最椀攀猀㨀㰀⼀唀㸀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
਍吀栀攀爀攀 愀爀攀 昀攀眀 搀椀昀昀攀爀攀渀琀 ∀匀渀愀瀀猀栀漀琀∀ 琀攀挀栀渀漀氀漀最椀攀猀 愀爀漀甀渀搀⸀㰀戀爀㸀ഀഀ
਍伀渀攀 瀀漀瀀甀氀愀爀 椀洀瀀氀攀洀攀渀琀愀琀椀漀渀 甀猀攀猀 琀栀攀 㰀䈀㸀∀䌀漀瀀礀 伀渀 圀爀椀琀攀∀㰀⼀䈀㸀 琀攀挀栀渀漀氀漀最礀Ⰰ 眀栀椀挀栀 椀猀 昀甀氀氀礀 戀氀漀挀欀 戀愀猀攀搀 漀爀 瀀愀最攀 戀愀猀攀搀⸀ 一攀琀䄀瀀瀀 搀漀攀猀 渀漀琀 甀猀攀 琀栀愀琀⸀㰀戀爀㸀ഀഀ In fact, NetApp uses "a new block write", on any change, and then sort of cleverly "remebers" inode pointers.
਍㰀戀爀㸀ഀഀ To understand this, lets review "Copy On Write" first, and then return to NetApp Snapshots.
਍㰀戀爀㸀ഀഀ ⇒ "Copy On Write" Snapshot:
਍㰀戀爀㸀ഀഀ Fig. 16. "Copy on Write" Snapshot (not used by NetApp).
਍㰀戀爀㸀ഀഀ ਍㰀戀爀㸀ഀഀ
਍䰀攀琀✀猀 猀愀礀 眀攀 栀愀瘀攀 愀 一䄀匀 瘀漀氀甀洀攀Ⰰ 眀栀攀爀攀 愀 渀甀洀戀攀爀 漀昀 搀椀猀欀戀氀漀挀欀猀 愀爀攀 椀渀瘀漀氀瘀攀搀⸀ ∀䌀漀瀀礀 漀渀 圀爀椀琀攀∀ 椀猀 爀攀愀氀氀礀 攀愀猀礀 琀漀 甀渀搀攀爀猀琀愀渀搀⸀㰀戀爀㸀ഀഀ Just before any block gets modified, the original block gets copied to a reserved space area.
਍夀漀甀 猀攀攀㼀 伀渀氀礀 琀栀攀 ∀搀攀氀琀愀猀∀Ⰰ 愀猀 漀昀 愀 挀攀爀琀愀椀渀 琀㴀琀㰀猀甀戀㸀　㰀⼀猀甀戀㸀 ⠀眀栀攀渀 琀栀攀 猀渀愀瀀猀栀漀琀 眀愀猀 愀挀琀椀瘀愀琀攀搀⤀Ⰰ 漀昀 愀 嘀漀氀甀洀攀 ⠀漀爀 昀椀氀攀Ⰰ 漀爀 眀栀愀琀攀瘀攀爀⤀㰀戀爀㸀ഀഀ gets copied. This is great, but it involves multple "writes": first, write the original block to a save place, then write the
਍琀栀攀 戀氀漀挀欀 眀椀琀栀 琀栀攀 渀攀眀 搀愀琀愀⸀㰀戀爀㸀ഀഀ
਍䤀渀 攀昀昀攀挀琀Ⰰ 礀漀甀 栀愀瘀攀 愀 戀愀挀欀甀瀀 漀昀 琀栀攀 攀渀琀椀琀礀 ⠀琀栀攀 嘀漀氀甀洀攀Ⰰ 琀栀攀 昀椀氀攀Ⰰ 琀栀攀 ∀眀栀愀琀攀瘀攀爀∀⤀ 愀猀 椀琀 眀愀猀 愀琀 琀㴀琀㰀猀甀戀㸀　㰀⼀猀甀戀㸀⸀㰀戀爀㸀ഀഀ
਍䤀昀Ⰰ 氀愀琀攀爀 漀渀Ⰰ 愀琀 琀㴀琀㰀猀甀戀㸀㄀㰀⼀猀甀戀㸀Ⰰ 礀漀甀 渀攀攀搀 琀漀 爀攀猀琀漀爀攀Ⰰ 漀爀 最漀 戀愀挀欀 琀漀 琀㴀琀㰀猀甀戀㸀　㰀⼀猀甀戀㸀Ⰰ 礀漀甀 渀攀攀搀 琀栀攀 瀀爀椀洀愀爀礀 戀氀漀挀欀 猀瀀愀挀攀Ⰰ 愀渀搀 挀漀瀀礀 琀栀攀 愀氀氀 爀攀猀攀爀瘀攀搀㰀戀爀㸀ഀഀ (saved) blocks "over" the modified blocks.
਍一漀琀攀 琀栀愀琀 琀栀攀 爀攀猀攀爀瘀攀搀 猀瀀愀挀攀 搀漀攀猀 一伀吀 挀漀渀琀愀椀渀 愀 昀甀氀氀 戀愀挀欀甀瀀⸀ 䤀琀✀猀 漀渀氀礀 愀 挀漀氀氀攀挀琀椀漀渀 漀昀 戀氀漀挀欀猀 昀爀攀攀稀攀搀 愀琀 琀㴀琀㰀猀甀戀㸀　㰀⼀猀甀戀㸀Ⰰ 戀攀昀漀爀攀 琀栀攀礀㰀戀爀㸀ഀഀ were modified between t=t₁ - t=t₀.
਍一漀爀洀愀氀氀礀Ⰰ 琀栀攀 爀攀猀攀爀瘀攀搀 猀瀀愀挀攀 眀椀氀氀 挀漀渀琀愀椀渀 洀甀挀栀 氀攀猀猀 戀氀漀挀欀猀 琀栀愀渀 琀栀攀 瀀爀椀洀愀爀礀 ⠀甀猀愀戀氀攀Ⰰ 眀爀椀琀愀戀氀攀⤀ 猀瀀愀挀攀Ⰰ 眀栀椀挀栀 洀攀愀渀猀 愀 氀漀琀 漀昀 猀愀瘀椀渀最㰀戀爀㸀ഀഀ of diskspace compared to a traditional "full" copy of blocks.
਍㰀戀爀㸀ഀഀ ⇒ "NetApp" Snapshot copy: general description (1)
਍㰀戀爀㸀ഀഀ You can schedule a Snapshot backup of a Volume, or you can make one interactively using an Ontap command or GUI tool.
਍匀漀Ⰰ 愀 一攀琀愀瀀瀀 匀渀愀瀀猀栀漀琀 戀愀挀欀甀瀀 椀猀 渀漀琀 愀渀 ∀漀渀最漀椀渀最 瀀爀漀挀攀猀猀∀⸀ 夀漀甀 猀琀愀爀琀 椀琀 ⠀漀爀 椀琀 椀猀 猀挀栀攀搀甀氀攀搀⤀Ⰰ 琀栀攀渀 椀琀 爀甀渀猀 甀渀琀椀氀 椀琀 椀猀 搀漀渀攀⸀㰀戀爀㸀ഀഀ
਍吀栀攀 洀攀挀栀愀渀椀挀猀 漀昀 愀 猀渀愀瀀猀栀漀琀 戀愀挀欀甀瀀 愀爀攀 瀀爀攀琀琀礀 ∀甀渀甀猀甀愀氀∀Ⰰ 戀甀琀 椀琀 猀甀爀攀 椀猀 㰀䤀㸀昀愀猀琀㰀⼀䤀㸀⸀㰀戀爀㸀ഀഀ
਍䘀椀最⸀ ㄀㜀⸀ 一攀琀䄀瀀瀀 匀渀愀瀀猀栀漀琀 挀漀瀀礀⸀㰀戀爀㸀ഀഀ
਍㰀椀洀最 猀爀挀㴀∀搀椀猀欀搀攀瘀椀挀攀猀㄀㐀⸀樀瀀最∀ 愀氀椀最渀㴀∀挀攀渀琀爀攀∀⼀㸀ഀഀ
਍㰀戀爀㸀ഀഀ It's better to speak of a "Snapshot copy", than of a "Snapshot backup", but most of us do not care too much about that.
਍䤀琀✀猀 愀渀 攀砀愀挀琀 猀琀愀琀攀 漀昀 琀栀攀 嘀漀氀甀洀攀 愀猀 椀琀 眀愀猀 愀琀 琀㴀琀㰀猀甀戀㸀　㰀⼀猀甀戀㸀Ⰰ 眀栀攀渀 椀琀 猀琀愀爀琀攀搀⸀㰀戀爀㸀ഀഀ
਍ ഀഀ With a snapshot running, WAFL takes a completely another approach than many of us are used to. If an existing "block" (that already contained data),
਍椀猀 最漀椀渀最 琀漀 戀攀 洀漀搀椀昀椀攀搀 眀栀椀氀攀 琀栀攀 戀愀挀欀甀瀀 爀甀渀猀Ⰰ 圀䄀䘀䰀 樀甀猀琀 琀愀欀攀猀 愀 渀攀眀 昀爀攀攀 戀氀漀挀欀Ⰰ 愀渀搀 瀀甀琀猀 琀栀攀 洀漀搀椀昀椀攀搀 戀氀漀挀欀 琀栀攀爀攀⸀㰀戀爀㸀ഀഀ The original block stays the same, and the inode (pointer) to that block is part of the Snapshot !
਍匀漀Ⰰ 琀栀攀爀攀 椀猀 漀渀氀礀 漀渀攀 眀爀椀琀攀 ⠀琀栀愀琀 琀漀 琀栀攀 渀攀眀 戀氀漀挀欀⤀⸀ 吀栀攀 椀渀漀搀攀 ⠀愀 瀀漀椀渀琀攀爀⤀ 漀昀 琀栀攀 漀爀椀最椀渀愀氀 戀氀漀挀欀 椀猀 瀀愀爀琀 漀昀 琀栀攀 匀渀愀瀀猀栀漀琀⸀㰀戀爀㸀ഀഀ
਍䤀琀 攀砀瀀氀愀椀渀猀 眀栀礀 猀渀愀瀀猀栀漀琀猀 愀爀攀 猀漀 椀渀挀爀攀搀愀戀氀礀 昀愀猀琀⸀㰀戀爀㸀 ഀഀ
਍㰀䈀㸀☀⌀㠀㘀㔀㠀㬀 ∀一攀琀䄀瀀瀀∀ 匀渀愀瀀猀栀漀琀 挀漀瀀礀㨀 琀栀攀 漀瀀攀渀 昀椀氀攀 瀀爀漀戀氀攀洀 ⠀㈀⤀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
਍䘀爀漀洀 伀渀琀愀瀀✀猀 瀀攀爀猀瀀攀挀琀椀瘀攀Ⰰ 琀栀攀爀攀 椀猀 渀漀 瀀爀漀戀氀攀洀 愀琀 愀氀氀⸀ 䠀漀眀攀瘀攀爀Ⰰ 洀愀渀礀 瀀爀漀最爀愀洀猀 爀甀渀 漀渀 䠀漀猀琀猀 ⠀匀攀爀瘀攀爀猀⤀ 愀渀搀 渀漀琀 漀渀 琀栀攀 䘀椀氀攀爀 漀昀挀漀甀爀猀攀⸀㰀戀爀㸀ഀഀ So, applications like Oracle, SQL Server etc.. have a completely different perspective.
਍㰀戀爀㸀ഀഀ The Snapshot copy might thus be inconsistent. This is not caused by Netapp. Netapp only produced a state image of pointers at t=t0.
਍䄀渀搀 琀栀愀琀 椀猀 愀挀琀甀愀氀氀礀 愀 最漀漀搀 戀愀挀欀甀瀀⸀㰀戀爀㸀ഀഀ
਍吀栀攀 瀀漀琀攀渀琀椀愀氀 瀀爀漀戀氀攀洀 椀猀 琀栀椀猀㨀 一攀琀䄀瀀瀀 挀爀攀愀琀攀搀 琀栀攀 猀渀愀瀀猀栀漀琀 愀琀 琀㰀猀甀戀㸀　㰀⼀猀甀戀㸀Ⰰ 搀甀爀椀渀最 琀栀攀 琀㰀猀甀戀㸀　㰀⼀猀甀戀㸀 琀漀 琀㴀琀㰀猀甀戀㸀㄀㰀⼀猀甀戀㸀 椀渀琀攀爀瘀愀氀⸀㰀戀爀㸀ഀഀ In that interval, a database file is fractioned, meaning that processes might have updated records in the databasefiles.
਍吀礀瀀椀挀愀氀 漀昀 搀愀琀愀戀愀猀攀猀 椀猀Ⰰ 椀猀 琀栀愀琀 琀栀攀椀爀 㰀䈀㸀 漀眀渀 挀栀攀挀欀瀀漀椀渀琀 猀礀猀琀攀洀 瀀爀漀挀攀猀猀㰀⼀䈀㸀 昀氀甀猀栀攀猀 搀椀爀琀礀 戀氀漀挀欀猀 琀漀 搀椀猀欀Ⰰ 愀渀搀 甀瀀搀愀琀攀㰀戀爀㸀ഀഀ fileheaders accordingly with a new "sequence number". If all files are in sync, the database engine considers the database
਍愀猀 ∀挀漀渀猀椀猀琀攀渀琀∀⸀ 䤀昀 琀栀愀琀✀猀 渀漀琀 搀漀渀攀Ⰰ 琀栀攀 搀愀琀愀戀愀猀攀 椀猀 ∀椀渀挀漀渀猀椀猀琀攀渀琀∀ ⠀猀漀 琀栀攀 搀愀琀愀戀愀猀攀 攀渀最椀渀攀 琀栀椀渀欀猀⤀⸀㰀戀爀㸀ഀഀ
਍䈀礀 琀栀攀 眀愀礀Ⰰ 椀琀✀猀 渀漀琀 搀愀琀愀戀愀猀攀猀 愀氀漀渀攀 琀栀愀琀 戀攀栀愀瘀攀 椀渀 琀栀愀琀 洀愀渀渀攀爀⸀ 䄀氀猀漀 愀氀氀 猀漀爀琀猀 漀昀 眀漀爀欀昀氀漀眀Ⰰ 洀攀猀猀愀最椀渀最Ⰰ 焀甀攀甀椀渀最 瀀爀漀最爀愀洀猀 攀琀挀⸀⸀㰀戀爀㸀ഀഀ show similar behaviour.
਍㰀戀爀㸀ഀഀ Although the Snapshot copy is, from a filesystem view, perfectly consistent, Server programs might think differently.
਍吀栀愀琀 琀栀甀猀 瀀漀猀攀猀 愀 瀀爀漀戀氀攀洀⸀㰀戀爀㸀ഀഀ
਍一攀琀愀瀀瀀 昀椀砀攀搀 琀栀愀琀Ⰰ 戀礀 氀攀琀琀椀渀最 礀漀甀 椀渀猀琀愀氀氀 愀搀搀椀琀椀漀渀愀氀 瀀爀漀最爀愀洀猀 漀渀 愀渀礀 猀漀爀琀 漀昀 䐀愀琀愀戀愀猀攀 匀攀爀瘀攀爀⸀㰀戀爀㸀ഀഀ These are "SnapDrive" and "SnapManager for xyz" (like SnapManager for SQL Server).
਍㰀戀爀㸀ഀഀ In effect, just before the Snapshot starts, the SnapManager asks the Database to checkpoint and to "shut up" for a short while (freeze as it were).
਍匀渀愀瀀䐀爀椀瘀攀 眀椀氀氀 搀漀 琀栀攀 猀愀洀攀 昀漀爀 愀渀礀 漀琀栀攀爀 漀瀀攀渀 昀椀氀攀猀礀猀琀攀洀 瀀爀漀挀攀猀猀攀猀⸀㰀戀爀㸀ഀഀ The result is good consistent backups at all times.
਍㰀戀爀㸀ഀഀ
਍㰀戀爀㸀ഀഀ ਍㰀栀爀⼀㸀ഀഀ

Chapter 9. A FEW NOTES ABOUT STORAGE ON UNIX, LINUX, and WINDOWS.

਍㰀栀爀⼀㸀ഀഀ ਍㰀戀爀㸀ഀഀ After a few words on storage in general and SAN's, let's take a look to how storage is viewed, used, and managed from some client Operating Systems.
਍㰀戀爀㸀ഀഀ Since this information really can be seen as a "independent" chapter, I have put this in a seperate file.
਍䤀琀 挀愀渀 戀攀 甀猀攀搀 愀猀 愀 昀甀氀氀礀 椀渀搀攀瀀攀渀搀攀渀琀 搀漀挀甀洀攀渀琀⸀㰀戀爀㸀ഀഀ
਍䤀昀 礀漀甀 愀爀攀 椀渀琀攀爀攀猀琀攀搀Ⰰ 瀀氀攀愀猀攀 猀攀攀㨀㰀戀爀㸀ഀഀ
਍㰀愀 栀爀攀昀㴀∀甀渀椀砀氀瘀洀⸀栀琀洀∀㸀匀漀洀攀 渀漀琀攀猀 漀渀 匀琀漀爀愀最攀 愀渀搀 䰀嘀䴀 椀渀 唀渀椀砀 猀礀猀琀攀洀猀⸀㰀⼀愀㸀㰀戀爀㸀ഀഀ
਍㰀戀爀㸀ഀഀ

Hope you think this document was a bit usefull...

਍㰀戀爀㸀ഀഀ
਍㰀戀爀㸀ഀഀ ਍ഀഀ
਍㰀戀爀㸀ഀഀ
਍㰀⼀戀漀搀礀㸀ഀഀ