Finding boot devices on a SAN

Robert Elliott relliott at
Thu May 11 17:56:19 PDT 2000

* From the T10 Reflector (t10 at, posted by:
* relliott at (Robert Elliott)
There doesn't seem to be a standard way for an operating system 
to find its boot images/boot volumes on disk drives scattered 
throughout a SAN.  Today, boot code is forced to do 
things like:

a) store disk target/LUN addresses in non-volatile memory 
on the host adapter card
b) store disk target/LUN addresses in non-volatile memory 
on the system
c) read from all the disk drives that are found, looking 
for signatures previously written

Option a) makes replacing failed host adapters difficult.  
It's not practical to move a ROM from one board to another.

Option b) is not practical because not all systems provide
such storage, and there don't seem to be industry-standard
ways for accessing such storage (at least in the x86 space).

Option c) wastes a lot of time and consumes a lot of bus 
bandwidth.  The signatures are not guaranteed to be unique 
across different operating systems, potentially leading 
to data corruption.

The Access Controls proposal introduces the concept of a
central management agent (PAM) that controls policies 
working with targets that implement those policies.  
Something like this could be useful for the boot problem.

Each target could maintain a list (similar to the access 
control list) indicating which initiators the management
agent has decreed are allowed to/should search for boot 
devices on that target.  The management agent would
be responsible for configuring the lists.  The target
would return an indication of whether the "bootable"
bit is set for the initiator making that inquiry. 

I imagine there are other attributes other than "bootable"
that might be useful too.  

Is there any interest in something like this?
Rob Elliott      UNIX mailto:relliott at    
Houston, TX        PC mailto:Robert.Elliott at
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list