Configuring vectors of logical storage units for data storage partitioning and sharing

Abstract

In a data storage subsystem providing data storage to host processors, a process of configuration defines a subset of the data storage that each host may access. A vector specification is a convenient mechanism for specifying a set of storage volumes that a host may access. For example, for each host processor, there is stored in memory of the data storage subsystem a list of contiguous ranges or vectors of the storage volumes that the host may access. To determine whether or not a specified logical volume number is included in the vector, a mudulus of the stride of the vector is computed from the difference between the address of the specified logical volume and the beginning address of the vector, and the modulus is compared to zero. To provide a mapping between logical unit numbers specified by the host and the logical volumes, a contiguous range of logical unit numbers may also be specified for each contiguous range or vector of storage volumes. The logical volume number is computed from a specified logical unit number by computing a difference between the specified logical unit number and the beginning logical unit number, multiplying the difference by the stride of the vector to produce a product, and adding the product to the beginning address of the vector.

Claims

What is claimed is:

1. A method of configuring data storage in a data storage subsystem for restricting access of host processors to the data storage, said method comprising:

a) subdividing the data storage into addressable logical storage units; and

b) assigning to each host processor a respective subset of the data storage to which access of said each host processor is restricted;

wherein the assignment of at least one respective subset includes at least one vector specification of a series of the addressable logical storage units, the addressable logical storage units in the series of addressable logical storage units having addresses that form a vector, the vector including a beginning address (BEGIN) and a stride (S) that is a difference between neighboring addresses of the addressable logical storage units in the series of addressable logical storage units, such that the addresses of the logical storage units in the series are BEGIN, BEGIN+S, BEGIN+2S, . . . , and wherein the stride (S) is a non-zero integer different from one; and

which includes storing the vector specification in memory of the data storage subsystem, and the vector specification stored in memory of the data storage subsystem includes a specification of the beginning address (BEGIN), a specification of the stride (S), and a specification of an ending address (END) of a last addressable logical storage unit in the series of the addressable logical storage units.

2. A method of configuring data storage in a data storage subsystem for restricting access of host processors to the data storage, said method comprising:

a) subdividing the data storage into addressable logical storage units; and

b) assigning to each host processor a respective subset of the data storage to which access of said each host processor is restricted;

wherein the assignment of at least one respective subset includes at least one vector specification of a series of the addressable logical storage units, the addressable logical storage units in the series of addressable logical storage units having addresses that form a vector, the vector including a beginning address (BEGIN) and a stride (S) that is a difference between neighboring addresses of the addressable logical storage units in the series of addressable logical storage units, such that the addresses of the logical storage units in the series are BEGIN, BEGIN+S, BEGIN+2S, . . . , and wherein the stride (S) is a non-zero integer different from one; and

which further includes operating the data storage subsystem to compute the addresses in the vector in order to report the logical storage units that a host processor may access.

3. The method as claimed in claim 2, wherein the data storage subsystem computes the addresses in the vector in response to a request from the host processor for a report of the logical storage units that are accessible to the host processor.

4. The method as claimed in claim 2, wherein the data storage subsystem reports to a system administrator at a graphical user interface the logical storage units that the host processor may access.

5. A method of configuring data storage in a data storage subsystem for restricting access of host processors to the data storage, said method comprising;

a) subdividing the data storage into addressable logical storage units; and

b) assigning to each host processor a respective subset of the data storage to which access of said each host processor is restricted;

wherein the assignment of at least one respective subset includes at least one vector specification of a series of the addressable logical storage units, the addressable logical storage units in the series of addressable logical storage units having addresses that form a vector, the vector including a beginning address (BEGIN) and a stride (S) that is a difference between neighboring addresses of the addressable logical storage units in the series of addressable logical storage units, such that the addresses of the logical storage units in the series are BEGIN, BEGIN+S, BEGIN+2S, . . . , and wherein the stride (S) is a non-zero integer different from one; and

which further includes the data storage subsystem determining whether or not an address specified by a host processor is an address within a vector of addresses of logical storage units that have been configured for access by the host processor, in order to grant the host processor access to a logical storage unit having the specified address when the specified address is within the vector of addresses of logical storage units that have been configured for access by the host processor, and to deny the host processor access to a logical storage unit having the specified address when the specified address is not within the vector of logical storage units that have been configured for access by the host processor.

6. A method of configuring data storage in a data storage subsystem for restricting access of host processors to the data storage, said method comprising:

a) subdividing the data storage into addressable logical storage units; and

b) assigning to each host processor a respective subset of the data storage to which access of said each host processor is restricted;

wherein the assignment of at least one respective subset includes at least one vector specification of a series of the addressable logical storage units, the addressable logical storage units in the series of addressable logical storage units having addresses that form a vector, the vector including a beginning address (BEGIN) and a stride (S) that is a difference between neighboring addresses of the addressable logical storage units in the series of addressable logical storage units, such that the addresses of the logical storage units in the series are BEGIN, BEGIN+S, BEGIN+2S, . . . , and wherein the stride (S) is a non-zero integer different from one; and

which includes assigning a range of contiguous logical unit numbers used by a host processor to the vector specification of a series of the addressable logical storage units to establish a mapping between the range of contiguous logical unit numbers used by the host processor and the series of the addressable logical storage units, and storing in memory a specification of the mapping between the range of contiguous logical unit numbers used by the host processor and the series of the addressable logical storage units.

7. The method as claimed in claim 6, wherein the data storage subsystem responds to a request from the host processor for access to a specified logical unit number by checking whether or not the specified logical unit number is within the range of contiguous logical unit numbers used by the host processor, and when the specified logical unit number is within the range of contiguous logical unit numbers used by the host processor, computing an address of a logical storage unit from the specified logical unit number, and accessing the logical storage unit having the address computed from the specified logical unit number.

8. A method of configuring data storage in a data storage subsystem for restricting access of host processors to the data storage, said method comprising:

a) subdividing the data storage into addressable logical storage units; and

b) assigning to each host processor a respective subset of the data storage to which access of said each host processor is restricted;

wherein the assignment of at least one respective subset includes at least one vector specification of a series of the addressable logical storage units, the addressable logical storage units in the series of addressable logical storage units having addresses that form a vector, the vector including a beginning address (BEGIN) and a stride (S) that is a difference between neighboring addresses of the addressable logical storage units in the series of addressable logical storage units, such that the addresses of the logical storage units in the series are BEGIN, BEGIN+S, BEGIN+2S, . . . , and wherein the stride (S) is a non-zero integer different from one;

wherein the vector represents addresses of logical storage units, each of said logical storage units is accessible to a respective different host processor that has access to no other logical storage unit having an address represented by the vector, and said each of said logical storage units is accessible to another host processor having access to all of the logical storage units having addresses represented by the vector.

9. A method of configuring data storage in a data storage subsystem for restricting access of host processors to the data storage, said method comprising:

a) subdividing the data storage into addressable logical storage units; and

b) assigning to each host processor a respective subset of the data storage to which access of said each host processor is restricted;

wherein the assignment of at least one respective subset includes at least one vector specification of a series of the addressable logical storage units, the addressable logical storage units in the series of addressable logical storage units having addresses that form a vector, the vector including a beginning address (BEGIN) and a stride (S) that is a difference between neighboring addresses of the addressable logical storage units in the series of addressable logical storage units, such that the addresses of the logical storage units in the series are BEGIN, BEGIN+S, BEGIN+2, . . . , and wherein the stride (S) is a non-zero integer different from one; and

wherein the assigning includes storing in memory of the data storage subsystem a specification of the logical storage units that said each host processor may access, the specification of the logical storage units that said each host processor may access including a list of contiguous ranges or vectors of addresses of the logical storage units that said each host processor may access.

10. The method as claimed in claim 9, wherein the assigning further includes storing in memory of the data storage subsystem a respective specification of a contiguous range of logical unit numbers that said each host processor may specify for each of the contiguous ranges or vectors of address of the logical storage units that said each host processor may access, so that a mapping is established between the logical unit numbers specified by said each host processor and the addresses of the logical storage units that said each host processor may access.

11. A data storage subsystem comprising, in combination:

data storage; and

a storage controller coupled to the data storage for controlling access to the data storage, the storage controller having at least one data port for linking the data storage to a plurality of host processors for transfer of data between the data storage and the host processors, wherein the storage controller is programmed to access addressable logical storage units of the data storage, and to restrict access of the host processors to the data storage by assigning to each host processor a respective subset of the data storage to which access of said each host processor is restricted, wherein the assignment of at least one respective subset includes at least one vector specification of a series of the addressable logical storage units, the addressable logical storage units in the series of addressable logical storage units having addresses that form a vector, the vector including a beginning address (BEGIN) and a stride (S) that is a difference between neighboring addresses of the addressable logical storage units in the series of addressable logical storage units, such that the addresses of the logical storage units in the series are BEGIN, BEGIN+S, BEGIN+2S, . . . , and wherein the stride (S) is a non-zero integer different from one.

12. The data storage subsystem as claimed in claim 11, wherein the storage controller is programmed to store the vector specification in memory of the data storage subsystem, wherein the vector specification stored in memory of the data storage subsystem includes a specification of the beginning address (BEGIN), a specification of the stride (S), and a specification of an ending address (END) of a last addressable logical storage unit in the series of the addressable logical storage units.

13. The data storage subsystem as claimed in claim 11, wherein the storage controller is programmed to compute the addresses in the vector in order to report the logical storage units that a host processor may access.

14. The data storage subsystem as claimed in claim 13, wherein the storage controller is programmed to compute the addresses in the vector in response to a request from the host processor for a report of the logical storage units that are accessible to the host processor.

15. The data storage subsystem as claimed in claim 13, wherein the data storage subsystem is programmed to report to a system administrator at a graphical user interface the logical storage units that the host processor may access.

16. The data storage subsystem as claimed in claim 11, wherein the storage controller is programmed to determine whether or not an address specified by a host processor is an address within a vector of addresses of logical storage units that have been configured for access by the host processor, in order to grant the host processor access to a logical storage unit having the specified address when the specified address is within the vector of addresses of logical storage units that have been configured for access by the host processor, and to deny the host processor access to a logical storage unit having the specified address when the specified address is not within the vector of logical storage units that have been configured for access by the host processor.

17. The data storage subsystem as claimed in claim 11, wherein the storage controller is programmed to assign a range of contiguous logical unit numbers used by a host processor to the vector specification of a series of the addressable logical storage units to establish a mapping between the range of contiguous logical unit numbers used by the host processor and the series of the addressable logical storage units, and to store in memory of the data storage subsystem a specification of the mapping between the range of contiguous logical unit numbers used by the host processor and the series of the addressable logical storage units.

18. The data storage subsystem as claimed in claim 17, wherein the storage controller is programmed to respond to a request from the host processor for access to a specified logical unit number by checking whether or not the specified logical unit number is within the range of contiguous logical unit numbers used by the host processor, and when the specified logical unit number is within the range of contiguous logical unit numbers used by the host processor, computing an address of a logical storage unit from the specified logical unit number, and accessing the logical storage unit having the address computed from the specified logical unit number.

19. The data storage subsystem as claimed in claim 11, wherein the vector represents addresses of logical storage units, each of said logical storage units is accessible to a respective different host processor that has access to no other logical storage unit having an address represented by the vector, and said each of said logical storage units is accessible to another host processor having access to all of the logical storage units having addresses represented by the vector.

20. The data storage subsystem as claimed in claim 11, wherein the storage controller is programmed to store in memory of the data storage subsystem a specification of the logical storage units that said each host processor may access, wherein the specification of the logical storage units that said each host processor may access includes a list of contiguous ranges or vectors of addresses of the logical storage units that said each host processor may access.

21. The data storage subsystem as claimed in claim 20, wherein the storage controller is further programmed to store in memory of the data storage subsystem a specification of a respective contiguous range of logical unit numbers that said each host processor may specify for each of the contiguous ranges or vectors of address of the logical storage units that said each host processor may access, so that a mapping is established between the logical unit numbers specified by said each host processor and the addresses of the logical storage units that said each host processor may access.

22. A machine-readable program storage device containing a program for a storage controller for controlling access of a plurality of host processors to data storage, wherein the program is executable by the storage controller to access addressable logical storage units of the data storage, and to restrict access of the host processors to the data storage by assigning to each host processor a respective subset of the data storage to which access of said each host processor is restricted, wherein the assignment of at least one respective subset includes at least one vector specification of a series of the addressable logical storage units, the addressable logical storage units in the series of addressable logical storage units having addresses that form a vector, the vector including a beginning address (BEGIN) and a stride (S) that is a difference between neighboring addresses of the addressable logical storage units in the series of addressable logical storage units, such that the addresses of the logical storage units in the series are BEGIN, BEGIN+S, BEGIN+2S, . . . , and wherein the stride (S) is a non-zero integer different from one.

23. The machine-readable program storage device as claimed in claim 22, wherein the program is executable by the storage controller to store the vector specification in memory of the storage controller, wherein the vector specification stored in memory of the storage controller includes a specification of the beginning address (BEGIN), a specification of the stride (S), and a specification of an ending address (END) of a last addressable logical storage unit in the series of the addressable logical storage units.

24. The machine-readable program storage device as claimed in claim 22, wherein the program is executable by the storage controller to compute the addresses in the vector in order to report the logical storage units that a host processor may access.

25. The machine-readable program storage device as claimed in claim 24, wherein the program is executable by the storage controller to compute the addresses in the vector in response to a request from the host processor for a report of the logical storage units that are accessible to the host processor.

26. The machine-readable program storage device as claimed in claim 24, wherein the program is executable by the storage controller to report to a system administrator at a graphical user interface the logical storage units that the host processor may access.

27. The machine-readable program storage device as claimed in claim 22, wherein the program is executable by the storage controller to determine whether or not an address specified by a host processor is an address within a vector of addresses of logical storage units that have been configured for access by the host processor, in order to grant the host processor access to a logical storage unit having the specified address when the specified address is within the vector of addresses of logical storage units that have been configured for access by the host processor, and to deny the host processor access to a logical storage unit having the specified address when the specified address is not within the vector of logical storage units that have been configured for access by the host processor.

28. The machine-readable program storage device as claimed in claim 22, wherein the program is executable by the storage controller to assign a range of contiguous logical unit numbers used by a host processor to the vector specification of a series of the addressable logical storage units to establish a mapping between the range of contiguous logical unit numbers used by the host processor and the series of the addressable logical storage units, and to store in memory of the storage controller a specification of the mapping between the range of contiguous logical unit numbers used by the host processor and the series of the addressable logical storage units.

29. The machine-readable program storage device as claimed in claim 28, wherein the program is executable by the storage controller to respond to a request from the host processor for access to a specified logical unit number by checking whether or not the specified logical unit number is within the range of contiguous logical unit numbers used by the host processor, and when the specified logical unit number is within the range of contiguous logical unit numbers used by the host processor, computing an address of a logical storage unit from the specified logical unit number, and accessing the logical storage unit having the address computed from the specified logical unit number.

30. The machine-readable program storage device as claimed in claim 22, wherein the program is executable by the storage controller to store in memory of the storage controller a specification of the logical storage units that said each host processor may access, wherein the specification of the logical storage units that said each host processor may access includes a list of contiguous ranges or vectors of addresses of the logical storage units that said each host processor may access.

31. The machine-readable program storage device as claimed in claim 30, wherein the program is further executable by the storage controller to store in memory of the storage controller a specification of a respective contiguous range of logical unit numbers that said each host processor may specify for each of the contiguous ranges or vectors of address of the logical storage units that said each host processor may access, so that a mapping is established between the logical unit numbers specified by said each host processor and the addresses of the logical storage units that said each host processor may access.

Description

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates generally to data processing networks and data storage subsystems, and more particularly to a data processing network in which a number of hosts can access volumes of data storage in a data storage subsystem.

2. Description of the Related Art

Due to advances in computer technology, there has been an ever increasing need for data storage in data processing networks. In a typical data processing network, there has been an increase in the number of volumes of data storage and an increase in the number of hosts needing access to the volumes. This has been especially true for networks of workstations. Not only have a greater number of workstations been added to the typical network, but also the increase in data processing capabilities of a typical workstation has required more data storage per workstation for enhanced graphics and video applications.

The increased demand for data storage in a network is typically met by using more storage servers in the network or by using storage servers of increased storage capacity and data transmission bandwidth. From the standpoint of cost of storage, either of these solutions appears to be satisfactory. However, a greater number of storage servers in a network substantially increases the cost of managing the storage. This increased cost of management often appears some time after installation, when one of the servers reaches its capacity and some of its volumes must be reassigned to less heavily loaded servers. Network administrators aware of the cost of storage management realize that network storage should be consolidated to the minimum possible number of servers. The management problem is reduced by reducing the number of objects to be managed.

Due to the storage needs of present networks and the desire to consolidate servers, it is practical to provide a single storage subsystem with up to 20 terabytes (TB) storage, or approximately 4000 logical volumes. It may be possible for any host to have access to any volume in a data storage subsystem to which the host has access. However, it may be desirable to restrict the set of volumes that can be seen by any one host. Restricted access is desirable for security of private data. For example, private volumes should be assigned to each host for storage of private data, and other hosts should not be permitted to see or modify the private volumes of other hosts. Moreover, the "boot" process for a host is slowed down by searching for and reporting all the volumes to which the host has access. Certain operating systems are limited by the number of storage devices that they can manage at a given period of time, and for a host running such an operating system, it is not only desirable but also necessary to limit the number of volumes that the host can access.

It is possible to restrict access of a host to a limited set of logical volumes in the data storage subsystem by restricting the set of logical volumes accessible through a particular port adapter of the storage subsystem and linking the host to only that particular port adapter. For convenience, however, there should not be any restrictions on which logical storage volumes are accessible from each port adapter. Otherwise, during a reconfiguration of the data processing system, it may be necessary to physically switch the links that are connected to the network ports of the hosts or the port adapters, for example by manually disconnecting and reconnecting the links to the ports. Even in the case where the data network has a fabric for automatically establishing a link between any of the hosts and any of the port adapters, the physical possibility of any port adapter to access any logical storage volume provides alternative data paths that could be used in case of port adapter failure or port adapter congestion. For example, if a host sends a data access request to a port adapter and receives a busy response from the port adapter, then the host can send the data access request to another port adapter. Port adapter congestion is likely, for example, if the storage subsystem is a continuous media server, in which video data is often streamed through a single port adapter to a host for a relatively long period of time.

SUMMARY OF THE INVENTION

In accordance with one aspect of the invention, there is provided a method of configuring data storage in a data storage subsystem for restricting access of host processors to the data storage. The method includes subdividing the data storage into addressable logical storage units, and assigning to each host processor a respective subset of the data storage to which access of said each host processor is restricted. The assignment of at least one respective subset includes at least one vector specification of a series of the addressable logical storage units. The addressable logical storage units in the series of addressable logical storage units having addresses that form a vector. The vector includes a beginning address (BEGIN) and a stride (S) that is a difference between neighboring addresses of the addressable logical storage units in the series of addressable logical storage units, such that the addresses of the logical storage units in the series are BEGIN, BEGIN+S, BEGIN+2S, . . . , and wherein the stride (S) is a non-zero integer different from one.

In accordance with another aspect, the invention provides a data storage subsystem. The data storage subsystem includes data storage, and a storage controller coupled to the data storage for controlling access to the data storage. The storage controller has at least one data port for linking the data storage to a plurality of host processors for transfer of data between the data storage and the host processors. The storage controller is programmed to access addressable logical storage units of the data storage, and to restrict access of the host processors to the data storage by assigning to each host processor a respective subset of the data storage to which access of the host processor is restricted. The assignment of at least one respective subset includes at least one vector specification of a series of the addressable logical storage units. The addressable logical storage units in the series of addressable logical storage units have addresses that form a vector. The vector includes a beginning address (BEGIN) and a stride (S) that is a difference between neighboring addresses of the addressable logical storage units in the series of addressable logical storage units, such that the addresses of the logical storage units in the series are BEGIN, BEGIN+S, BEGIN+2S . . . S , and wherein the stride (S) is a non-zero integer different from one.

In accordance with a final aspect, the invention provides a machine-readable program storage device containing a program for a storage controller for controlling access of a plurality of host processors to data storage. The program is executable by the storage controller to access addressable logical storage units of the data storage, and to restrict access of the host processors to the data storage by assigning to each host processor a respective subset of the data storage to which access of said each host processor is restricted. The assignment of at least one respective subset includes at least one vector specification of a series of the addressable logical storage units. The addressable logical storage units in the series of addressable logical storage units have addresses that form a vector. The vector includes a beginning address (BEGIN) and a stride (S) that is a difference between neighboring addresses of the addressable logical storage units in the series of addressable logical storage units, such that the addresses of the logical storage units in the series are BEGIN, BEGIN+S, BEGIN+2S . . . , and wherein the stride (S) is a non-zero integer different from one.

BRIEF DESCRIPTION OF THE DRAWINGS

Other objects and advantages of the invention will become apparent upon reading the following detailed description with reference to the accompanying drawings wherein:

FIG. 1 is a block diagram of a data processing system including a cached storage subsystem linked by a data network to a multiplicity of host processors;

FIG. 2 is a block diagram of the data processing system of FIG. 1 further showing a typical fault-tolerant implementation for the data network;

FIG. 3 is a generalized block diagram of a node linked to the data network of FIG.

FIG. 4 is a block diagram of the data processing system of FIG. 1 showing a port adapter in the cached storage subsystem using a volume access table for assignment of logical storage volumes to respective host controller ports;

FIG. 5 is a diagram showing a simplified construction that could be used for the volume access table introduced in FIG. 4;

FIG. 6 is a diagram of a volume list entry defining a vector of logical storage volumes in a disk spread;

FIG. 7 is a block diagram of the cached storage subsystem showing further data structures used with the volume access table stored in port adapter memory;

FIG. 8 is a diagram showing a preferred construction for a volume access table stored in the cache memory as introduced in FIG. 7;

FIG. 9 is a diagram showing a preferred construction for the volume access table stored in port adapter memory;

FIG. 10 is a diagram of a directory for searching the volume table of FIG. 9;

FIG. 11 is a flowchart of a microcode routine executed by a port adapter of the cached storage subsystem of FIG. 1 when using the volume access table of FIG. 5 or FIG. 9 in response to a "Report LUNs" or access request by a host processor;

FIG. 12 is a flowchart of a microcode routine executed by a port adapter of the cached storage subsystem of FIG. 1 when converting the vector representation of FIG. 6 to a list of logical storage volume numbers;

FIG. 13 is a flowchart of a microcode routine executed by a port adapter of the cached storage subsystem of FIG. 1 when determining whether a specified logical storage volume is included in a disk spread defined by the vector representation of FIG. 6;

FIG. 14 is a graphical display of disk spreads in a two-dimensional volume space;

FIG. 15 is a graphical display of disk spreads in a three-dimensional volume space;

FIG. 16 is a flowchart of a microcode routine executed by a port adapter of the cached storage subsystem of FIG. 1 for volume configuration when installing the storage subsystem into the data processing system of FIG. 1;

FIG. 17 is a flowchart of a microcode routine executed by a port adapter of the cached storage subsystem of FIG. 1 when notified of a network state change such as a host controller boot;

FIG. 18 is a flowchart of a procedure performed by a system administrator during host controller replacement;

FIG. 19 is a diagram of a volume list that comprises a mapping table for mapping logical unit numbers (LUNs) to logical storage volume numbers;

FIG. 20 is a diagram of a volume list that comprises a mapping table for mapping ranges of LUNs to vectors of logical storage volume numbers;

FIG. 21 is a schematic diagram of the data processing system of FIG. 1 showing one of the port adapters programmed to provide virtual ports for access to respective groups of logical storage volumes;

FIG. 22 is a schematic diagram of a data processing system in which port adapters are programmed to permit a host to access the same virtual ports through the physical ports of more than one of the port adapters.

FIG. 23 a is block diagram of data structures of volume access and mapping information stored in memory of port adapters of the storage subsystem of FIG. 21 or FIG. 22;

FIG. 24 is a diagram of a virtual port host table included in the volume access and mapping information of FIG. 23;

FIG. 25 is a diagram of a virtual port mapping table included in the volume access and mapping information of FIG. 23;

FIG. 26 is a flow chart of a routine performed by a port adapter when reporting the virtual ports accessible to a host controller port;

FIG. 27 is a first sheet of a flow chart of a routine performed by a port adapter when responding to a volume access request or "Report LUNs" request from a host;

FIG. 28 is a second sheet of the flow chart begun in FIG. 27;

FIG. 29 is a diagram of a display generated by a graphical user interface to show a mapping relationship between logical volumes, storage adapter ports, and LUNs at a virtual port;

FIG. 30 is a diagram of a display generated by a graphical user interface to establish a mapping between volumes accessible at a virtual port for a host and the LUNs at the virtual port;

FIG. 31 is a block diagram of a semiconductor integrated circuit chip capable of authenticating itself in a secure fashion;

FIG. 32 is a block diagram showing semiconductor integrated circuit chips in accordance with FIG. 31 being used in the data processing system of FIG. 1 to permit a port adapter to authenticate the identity of host controllers;

FIG. 33 is a flowchart of a "challenge-response" procedure used by the port adapter and host controllers of FIG. 32 to permit the port adapter to authenticate the identity of a host controller.

FIG. 34 is a block diagram showing components of a Fibre Channel Frame;

FIG. 35 is a first sheet of a flowchart of a procedure used by the port adapter and host controllers of FIG. 32 to permit the port adapter to authenticate each message from a host controller;

FIG. 36 is a second sheet of the flowchart begun in FIG. 35;

FIG. 37 is a block diagram of a storage network configuration especially suited for up to 800 workstations;

FIG. 38 is a block diagram of a storage network configuration especially suited for up to 3300 workstations;

FIG. 39 is a block diagram of a storage area network providing fault tolerance and failover capability for hosts and storage subsystems in the network; and

FIG. 40 is a block diagram of a storage area network similar to that shown in FIG. 39 but including additional network loops for higher throughput.

While the invention is susceptible to various modifications and alternative forms. specific embodiments thereof have been shorn in the drawings and will be described in detail. It should be understood, however, that it is not intended to limit the invention to the particular forms shown, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the scope of the invention as defined by the appended claims.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

With reference to FIG. 1 of the drawings, there is shown a cached storage subsystem 20 connected via a data network 21 to a plurality of hosts 22, 23, 24, 25. The cached storage subsystem 20 includes storage volumes 26 and a storage controller 27 for controlling access of the hosts to the storage volumes. The storage volumes are logical units of storage distributed over one more storage devices 28, 29, 30, and 31. The storage devices are magnetic disk drives, optical disk drives, tape drives, solid-state memory devices, or other storage devices capable of providing nonvolatile data storage. Presently the preferred storage devices are magnetic disk drives each having a storage capacity of at least 46 gigabytes.

The storage controller 27 includes a dual port cache memory 32, a plurality of port adapters 35, 36, and a plurality of storage adapters 37, 38. The cache memory 32 is accessed via any one of two back-plane busses 33, 34. Each of the port adapters 35, 36 link the data network 21 to each of the two back-plane busses 33, 34. Each of the storage adapters 37, 38 links a respective set of the storage devices 28, 29, 30, 31 to each of the two back-plane busses 33, 34. For example, the cached storage subsystem includes up to eight storage adapters and up to eight port adapters, and each port adapter provides two independent data ports to the data network.

When a port adapter 35 or 36 receives a storage access request from one of the hosts 22, 23, 24, 25, the port adapter accesses a directory in the cache memory 32 to determine whether or not the data to be accessed resides in the cache memory. If the data to be accessed resides in the cache memory, then the port adapter accesses the data in the cache memory. If the data to be accessed does not reside in the cache memory, then the port adapter forwards a storage access request to the storage adapters 37, 38. One of the storage adapters 37, 38 responds to the storage access request by performing a logical-to-physical translation to determine where the data to be accessed resides on the storage devices, and reads the data from the storage devices and writes the data to the cache memory, for access by the port adapter. The storage adapters 37, 38 also perform a write-back operation to ensure that that data written to the cache memory 32 by the port adapters eventually becomes written to the storage volumes 26.

The cache memory 32 ensures that data frequently accessed by the hosts is likely to be found in cache in order to avoid the data access time of the storage devices and in order to minimize loading on the storage adapters and the port adapters. Consolidation of network storage into a large cached storage subsystem provides a benefit that cache resources are consolidated into one large cache, which is more efficient than a number of smaller caches having in total the same cache memory capacity. A large cache is more likely to contain the most recently accessed data than the combined cache memory of the smaller caches.

The storage subsystem 20 is constructed for high data availability so that a single high-capacity storage subsystem is at least as fault-tolerant as a local collection of conventional network storage servers. Fault tolerance is ensured by dual, redundant components and busses in the path from any one of the port adapters 35, 36 to any one of the storage devices 28, 29, 30, and 31. Mirroring or RAID (redundant array of inexpensive disks) techniques ensure that the storage adapters 37, 38 can recover data in the event of failure of any one of the storage devices. In a similar fashion, the data network 21 can be made fault tolerant by ensuring that each of the hosts 22, 23, 24, 25 has independent paths through the data network 21 to each of two of the port adapters 35, 36, as will be further described below with reference to FIG. 2.

In a preferred form of construction, the cache memory 32 is composed of dynamic RAM memory cards mounted in a card-cage or main-frame, and the port adapters and storage adapters are programmed micro-processor cards that are also mounted in the card-cage or main-frame. Each port adapter 35, 36 has one or more processors for handling the communication protocol of the data network 21 and communicating with the cache memory busses 33, 34. Each storage adapter 37, 38 has one or more processors for handling the communication protocol of the storage devices and for communicating with the cache memory busses 33. 34. For example, the links between the storage adapters 37 and the storage devices 28, 29, 30, and 31 are FWD (fast, wide, differential ) SCSI or Fibre Channel fiber-optic loops. The port adapters 35, 36 can be programmed to communicate with the network via any number of communication and/or network protocols, such as Bus and Tag CKD, ESCON, SCSI, Ethernet, FDDI, ATM, DS1, DS3, T3, TCP, UDP, NFS, SNMP, and Fibre Channel. Further details regarding the preferred construction and operation of the cached storage subsystem 20 are disclosed in Yanai et al., U.S. Pat. No. 5,206,939, issued Apr. 27, 1993; Yanai et al. U.S. Pat. No. 5,335,352, issued Aug. 2, 1994; and Yanai et al. U.S. Pat. No. 5,381,539, issued Jan. 10, 1995; all incorporated herein by reference.

Referring to FIG. 2, there is shown a fault-tolerant way of connecting a large number of hosts 22, 23, 24, 25 to the cached storage subsystem 20. In this example, the data network 21 includes a respective loop 41, 42, 43, 44 connected to each port of the port adapters 35, 36, and each host has at least two ports, each of which is connected to a respective loop connected to the port of a different one of the port adapters. Therefore, if there is a single failure of any one of the loops or a single failure of any one of the port adapters, there will still be an operational path from each host to the internal back-plane busses (33, 34 in FIG. 1) in the cached disk storage subsystem. The loops 41, 42, 43, 44, for example, operate in accordance with the Ethernet or Fibre Channel standards. Each loop could connect up to fifty hosts, for a total of 400 hosts connected via dual-redundant paths from eight port adapters. For workstation hosts where dual-redundant paths would not be needed, only one port of each workstation could be connected to the network 21, so that up to 800 workstations could be connected to the storage subsystem by connecting this single port of each workstation to only one of sixteen loops, as will be further described below with reference to FIG. 37.

It is possible to replace each of the loops 41-44 in FIG. 2 with a switch, or to use switches together with loops for connecting hosts to the storage subsystem, as will be further described below with reference to FIG. 38. In general, for a given number of ports, a loop will be less expensive that a switch, but a switch may provide more bandwidth that a loop. The additional bandwidth of a switch may be needed for ensuring concurrent host access to the storage subsystem or for supporting bandwidth-intensive applications such as interactive video applications.

In general, the data network 21 of FIG. 1 could have various topologies and simultaneously use a number of different communication protocols. For example, the data network 31 could connect ports of various devices by dedicated port-to-port connections (i.e., so-called point-to-point connections), loops, or switches, or combinations of these connections. In addition to switches, the data network 21 could include other connectivity devices such as hubs, bridges and routers. The data network 31 could include additional processors or computers for buffering or streaming data from the cached storage subsystem to hosts or to archival storage such as a tape library. For example, the use of a cached storage subsystem in connection with stream servers, a tape library, and an ATM switch, for continuous-media isochronous data access, and on-line backup storage, is described in Vishlitzky et al., U.S. Pat. No. 5,737,747 issued Apr. 7, 1998.

The data network 21 could also include one or more additional cached storage subsystems, preferably at different geographical locations, to provide redundancy and protection from a catastrophic failure of the cached storage subsystem 20, as will be further described below with reference to FIGS. 39 and 40. The cached storage subsystems could be linked for automatic remote mirroring of data to provide recovery from a disaster, as described in Yanai et al., U.S. Pat. No. 5,544,347 issued Aug. 6, 1996, incorporated herein by reference, and in Yanai et al., U.S. Pat. No. 5,742,792 issued Apr. 21, 1998 (Ser. No. 08/654,511 filed May 28, 1996), incorporated herein by reference.

Because the data network 21 could have various topologies, it is desirable to provide a facility for enabling any device in the network to determine the configuration of at least that portion of the network that is accessible to the device. With reference to FIG. 3, for example, there is shown a node 50 having a number of ports, including ports 51 and 52, which may be connected to the data network 21. In this context, the node 50 can represent any device having ports which may be connected to the data network 21. The node also has a number of entities 53, 54, 55, 56, which are accessible through one or more of the ports, and which are identified by logical unit numbers (LUNs), each of which is unique for any single node. For example, if the node 50 is a storage subsystem, each logical storage volume is assigned a unique LUN. As will be further described below, it is also possible to establish a mapping between the LUNs as specified by or reported to a host and the logical volumes, so that one logical volume could be mapped to more than one LUN. Each port 51, 52 is constructed or programmed to respond to a "Report LUNs" command by returning a list of LUNs which are accessible from the port. In the fashion, a host can send "Report LUNs" commands to each port of each storage subsystem to which it is connected, to obtain a list of the logical volumes to which the host is connected. This is typically done by a host operating system at "boot" time.

The format for the Report LUFNs command and the manner of its use by the host is determined by the protocol used by the network. For example, for a host connected to a storage node via a SCSI link, then the host addresses the storage volume by a Bus/Target/LUN triple, and the host can send a SCSI "Report LUNs" command over the bus to each target on the bus to obtain a list of LUTNs accessible through each target. Such a Report LUNs command is subsumed in the Fibre Channel standards, which define additional capabilities for permitting a host to determine the present configuration of a network to which the host is connected. The Fibre Channel standards are currently being developed by the American National Standards Institute (ANSI).

In a Fibre Channel network, each port has a 64-bit port identifier called a "World Wide Name" (WWN). To ensure that the WHEN is unique, for example, it may include a unique identifier of the manufacturer of the device including the port (e.g., an Organizationally Unique Identifier as registered with the IEEE in New York, N.Y.), and the manufacturer's serial number of the device. A logical storage volume in a Fibre Channel storage subsystem therefore can be identified by the combination of the WWN of the storage subsystem and the LUN of the logical volume.

In a Fiber Channel network, the portion of the network connected to each port has one of four distinct topologies; namely, point-to-point, private loop, public loop, and fabric. A point-to-point topology has one port connected directly to one other port. A loop is a single simplex media linking three or more nodes such that transmission can occur between a single pair of nodes on the media at any given time. A hub is a specific implementation of a loop in which a node can be inserted into or removed from the hub without breaking the loop. A private loop is a dedicated or closed loop. A public loop is a loop attached to a node of a fabric. A fabric is a topology that permits multiple simultaneous transmissions between pairs of nodes connected to it. The fabric routes or switches data frames from a source node to a destination node. A switch is an implementation of the fabric topology.

In a Fiber Channel network, a node of a host directly connected to a loop can determine all other nodes in the loop by polling. A response from a node on the loop can indicate whether or not the responding node is or is not a fabric port. When a node is identified, its associated LUNs can be requested b sending a Report LUNs request to the node. A node of a fabric port can be further interrogated about the identity of other nodes of the fabric to which the node of the fabric port is directly connected through the fabric. For example, associated with the fabric is a "name server" that will respond with a list of nodes directly accessible through the fabric. The name server has a predefined address on the fabric. A node of the host can also probe the configuration of a point-to-point connection or loop connected to each node directly accessible through the fabric, by addressing a port of the fabric to route interrogation requests to other ports.

A request from one port to another on a loop or fabric must identify the destination port so that only the destination port will respond to the request. A request from one port to another on a loop or fabric must also identify the source of the request so that a response can be directed back to the source. Although the WWNs of the source and destination ports could be used in each request to uniquely identify the source and destination ports, each WWN contains so many bits that an undue amount of transmission bandwidth and data processing capability would be expended if the source and destination WWNs were used in each request. Therefore, it is desirable to assign a temporary identifier to each port in the data network in such a fashion that the identifier is unique to the configuration of the network at any given time, but not necessarily unique to each port for all time. Therefore, such a temporary identifier can have fewer bits than a WWN yet uniquely identify a source or desired destination of a request transmitted through the network.

The Fiber Channel standards specify that data is transmitted over the Fiber Channel network in packets having a predefined format and such a packet is called a "frame." Each frame includes a source address (S_ID) and a destination address (D_ID). The S_ID is a temporary identifier of the port which is the source of the frame, and the D_ID is a temporary identifier of the port which is the desired destination of the frame. Further details regarding the format of the frame are described below with reference to FIG. 34.

The use of temporary rather than permanent identifiers for source and destination addresses in the network introduces the problem of assigning and reassigning the temporary identifiers when the configuration of the network is defined and changed. For example, when a private loop is changed into a public loop by connecting a port of a switch to the loop, temporary addresses must be assigned to other ports of the switch and to the ports of devices that become connected to those other ports.

If a Fiber Channel network includes a fabric, then the temporary identifiers of ports in the network are assigned by the fabric at the time of a fabric login if the fabric supports a fabric login. Otherwise, the temporary identifiers must be known by the ports implicitly. For example, in a fabric containing only one switch, when that one switch is powered on or reset, then that one switch implicitly knows its own ports, and a "domain controller" of the switch searches for nodes connected to the switch ports, assigns temporary IDs to all the nodes that become known to it, and reports to the ports that it has found the temporary IDs assigned to them During this fabric login process, a "name server" of the fabric may build a table of the WWNs of the ports that are known to the fabric and their corresponding temporary IDs. If the Fibre Channel network includes multiple switches, then only one of them, designated as the master switch, assigns ranges of temporary IDs to be used by each of the switches during the fabric login The Fibre Channel network can be constructed so that the name server automatically obtains information from the domain controller when the domain controller learns about the ports that become connected to the network, or the Fibre Channel network can be constructed so that a port must log into the domain controller to obtain its temporary ID, and then log into the name server so that the name server obtains the temporary ID of the port. The first case is known as an implicit name server login, and the second case is known as an explicit name server login.

After an initial fabric login process, it is possible for the configuration of the network to become changed as a result of addition or replacement of devices having ports connected to the network. The data processing system could be shut down and then reconfigured so that the new ports become known implicitly, or a fabric login could be initiated so that temporary IDs become assigned to the new ports. In the case of a data network having a fabric supporting a fabric login, it is also possible for a device added to the network to initiate a process of obtaining temporary IDs for its ports by requesting a "port login" from the fabric.

The Fiber Channel specifications provide a mechanism for the network to automatically detect certain changes of state which may indicate that the configuration of the system has changed. For example, idle signals are transmitted over the links to enable detection of link failure. Frame transmission errors are detected by cyclic redundancy checks and sequence identification numbers in the frames. When transmission over a link is restored after detection of a link failure, a fabric may require the ports connected by the link to login for reassignment of temporary IDs to the ports. A fabric may also support a "state change notification" process in which ports having operational links to the fabric may request to be notified by the fabric when a state change is detected.

As described above, the data processing system in FIG. 1 has facilities for ensuring that the logical storage volumes 28, 29, 30, and 31 are accessible to the hosts 22, 23, 24, 25. It is not only physically possible for any host to have access to any logical volume in the data storage subsystem, but for fault tolerance is desirable for there to be at least two independent paths through the data network 21 and through the cached storage subsystem from each host to each logical storage volume.

Although it may be physically possible in the data processing system of FIG. 1 for any host to have access to any logical storage volume, it may be desirable to restrict the set of volumes that can be seen by any one host. Certain "private" volumes should be assigned to each host and other hosts should not be permitted to see or modify the private volumes of other hosts. Moreover, the "boot" process for a host is slowed down by searching for and reporting all the volumes to which the host has access. Certain operating systems are limited by the number of devices that they can handle at a given period of time, and for a host using such an operating system, it is not only desirable but also necessary to limit the number of volumes that the host can access.

The problem of restricting the set of volumes that can be seen by any one host is solved by a method of named groups and/or a method of virtual ports. The method of named groups is applicable to all Fiber Channel topologies for the connections of hosts to one or more ports of a storage controller. The method of virtual ports causes at least one port of the storage controller to appear as if it were a port of a fabric. The method of virtual ports could cause the port of the storage controller to appear as if it were a Fibre-Channel FL_Port (a port in a loop that is part of a fabric), E_Port (a port that is an interlink between two switches), or F_Port (fabric port). The two methods could be used at the same time in the same storage controller. In either the method of named groups or the method of virtual ports, the limited set of volumes accessible to a host can be specified by a list of logical volumes in the limited set, or by a procedure that defines the limited set of volumes. An example of a specification for a procedure that defines the limited set of volumes is a vector defining what will be called a "disk spread."

Referring to FIG. 4, there are shown further details of the data processing system of FIG. 1. In FIG. 4, each of the hosts 22, 23, 24 and 25 is shown to have a respective host controller 61, 62, 63, 64 for each host port 65, 66, 67, 68 directly linked to the port adapter 35. In the context of this specification, the term "host controller" refers to the controller of the host ports on the data network. In the data processing art, such a host controller is often referred to as a "host bus adapter" or "HBA". The term "host controller" will be used instead to avoid confusion with the "port adapter" of the storage controller or storage subsystem. Each host controller 61, 62, 63, 64 is programmed with a unique WWN for circuitry in the host controller for each of the respective ports 65, 66, 67, 68. In other words, if a host controller is replaced with a different host controller, the WWN associated with the host port will change. Moreover, a host controller may provide more than one port, and the host controller is programmed with a different WWN for each of its ports.

As further shown in FIG. 4, the port adapter 35 includes port circuitry 71 and 72 for each of its two ports 73 and 74. The port circuitry, for example, includes application-specific integrated circuits (ASICs) for communicating over the loops 41 and 43 in accordance with the Fibre Channel standards. The port circuitry is connected to an input/output bus 75 of a microprocessor 76. The microprocessor 76 is connected to a random access memory 77 by a memory bus 78. The microprocessor 76 is also interfaced to the storage controller busses 33 and 34. The memory 77 stores microcode 79 executed by the microprocessor 76.

Storage Volume Partitioning by Named Groups

In order to restrict the set of volumes that can be seen by any one host, the memory 77 of the port adapter 35 stores information defining a correspondence between hosts in the data processing system and the set of volumes accessible to each host through the port adapter. For example, a volume access table 80 and volume lists 81 are stored in the memory 77. The volume access table specifies a correspondence between hosts and respective lists of volumes accessible to the hosts. A back-up copy of the volume access table and volume list could be stored in one of the storage volumes of the cached storage subsystem.

The information in the volume access table 80 and the volume lists 81 can be accessed by a system administrator viewing a display 91 and operating a keyboard 92 of a service processor 93 interfaced to the controller busses 33, 34. The display 91, keyboard 92, and service processor 93, for example, are provided by a conventional lap-top computer mounted behind a door (not shown) in the cabinet (not shown) of the storage controller. The service processor 93, for example, is programmed to provide a graphical user interface for volume configuration, partitioning, and other storage management functions. The service processor also has a floppy-disc drive for down-loading of the microcode 79 from a from a floppy-disc program carrier 95. Alternatively, a system administrator at a remote terminal or host could access the information in the volume access table 80 and volume lists 81 and down-load microcode via a modem or dedicated link or via the data network (21 in FIG. 1) using an appropriate communications protocol such as the Simple Network Management Protocol (SNMP).

Referring to FIG. 5, there is shown a simplified construction for a volume access table 82. A preferred form of construction for the volume access table 80 in FIG. 4 will be described below with reference to FIGS. 7 to 10. In the simplified construction of FIG. 5, each entry in the volume access table includes a volume group name, a host controller port WWN, a host controller port S_ID, a private/shared flag, and a pointer to a volume list. The volume group name includes a host name and a number identifying a particular one of possibly many host ports linked to the port adapter. The volume group name provides a stable and unique identification number for a group of logical storage volumes to be accessed from a host port. At any given time, the S_ID and host controller port WWN also provide unique identification numbers for the volume group, but the S_ID is changed upon booting of the host controller, and the WWN is changed upon controller replacement. Using a stable ID permits automation of booting, and simplifies management of controller replacement. Moreover, by providing a path through the data network from a host controller to each port adapter and by including an entry in the volume access table in each port adapter defining a volume group name for the host controller, it is possible to provide port independence in the sense that a host controller may access its corresponding set of logical volumes through any of the port adapters. When set, the private/shared flag indicates that all of the logical volumes in the volume list are private and no permission is needed from a lock manager before the host controller port can accessing any logical volume in its assigned volume list.

The volume group names and the volumes in each volume list are defined by the system administrator. The host controller port WWNs are entered into the volume access table 80 automatically during installation or replacement of a host controller. The host controller S_ID is entered and updated automatically during each boot. The system administrator defines the host names, for example, by sequentially assigning numbers to the hosts. The host names are also known to the hosts, so that the relationship between each host and the volumes assigned to the host can be re-established automatically if both the S_IDs and WWNs would happen to change, for example as a result of host controller replacement and a change in the configuration of the data network. In this situation, the host controller port can transmit its corresponding group name to the storage subsystem during a login process or in response to a request from the storage subsystem in response to a state change notification so that the storage subsystem can reestablish the relationship of the host controller port's volume group name and volume list with respect to its new WWN and S_ID.

In the table 82 of FIG. 5, for example, the entry "HOST22-1" indicates the first controller port of host no. 22, and it could be coded as a number 221, although the entry could be displayed as "HOST22-1" for viewing by the system administrator. The other entries in the table are shown as hexadecimal numbers. The volume access table itself can have any suitable organization in the port adapter memory 77, such as a fixed-size block of contiguous memory locations, or doubly-linked lists of the table entries.

The specification of the particular volumes in a volume group should permit flexibility in assigning a variable number of volumes to each group, and also permit flexibility in defining overlap between the groups corresponding to certain volumes that are shared by the host processors. However, controller memory is a valuable resource, and it is necessary to rapidly determine whether or not a volume specified by a storage access request from a host controller port is included in the port's volume list. The searching of a long list of pseudo-random logical volume numbers, for example, would directly impact storage access time. Search time is especially critical in a cached storage system, since the search time may be comparable to the data access time if the requested data resides in the cache memory. In any case, the assignment of a long list of pseudo-random logical volume numbers complicates the storage management problem, because it is difficult for the storage administrator to comprehend how the volumes are assigned or shared when the volumes in the volume list become nearly full and additional volumes must be allocated to the hosts.

Hashing techniques can he used to search a long volume list rather efficiently, for example, by using the last couple of digits of the specified logical volume number as a hash table index. Since the list is changed infrequently, the list entries can be sorted for a binary search procedure. Moreover, it is possible to reduce the number of entries in the volume list and speed up the search process by specifying a range or vector of volume numbers in each list entry. Shown in FIG. 6, for example, is a volume list entry 83 specifying a beginning volume number 84, an ending volume number 85, and a value 86 of one minus a stride (S). For example, the beginning volume number 84 is coded in three bytes, the ending volume number is coded as three bytes, and the stride is coded as two bytes. The stride (S) indicates the difference between neighboring volume numbers of the volumes in a disk spread. The stride (S), for example, is a positive integer ranging from 1to 256 decimal.

Referring to FIG. 7, there is shown a preferred form of construction in which the volume access table 80 in the memory 77 of the port adapter 35 stores only the volume access information need for processing of a data access request by a host controller, and an additional volume access table 88 in the cache memory 32 stores information that appears in the table 82 of FIG. 5 but is not needed to process a data access request by a host controller. The table 80 in the port adapter memory 77 is further identified as a "transient" volume access table because it includes the transient S_IDs of the host controller ports that have logged in to the port adapter 35. The table 88 in the cache memory 32 is further identified as a "persistent" volume access table because it includes the relatively permanent WWNs of the host controller ports that have logged in to the port adapter 35. As further shown in FIG. 7, the port adapter 36 has a similar transient volume access table 87 in its port adapter memory 90. The transient volume access table 87 includes the transient S_IDs of the host controller ports that have logged in to the port adapter 36. In this case, example, the persistent volume access table 88 includes the WWNs of the host controller ports that have logged in to the port adapter 90 in addition to the WWNs of the host controller ports that have logged in to the port adapter 35. It is desirable to share a persistent volume access table among a number of transient volume access tables in the case where a host controller may access the same volume group from the ports of different port adapters, since this avoids duplication of persistent volume access table entries that would otherwise occur. Also shown in FIG. 7 are volume attributes and locking information 89 stored in the cache memory 32, and respective table directories 97, 98 that are stored in the port adapter memories 77, 90 and used to speed up the process of searching the transient volume access tables 80 and 87.

The persistent volume access table 88 and the volume attributes and locking information 89 also reside in a logical storage volume and be maintained in cache in a fashion similar to any other logical storage volume accessed by a host controller. However, it is preferred to locate the persistent volume access table 88 and the volume attributes and locking information in a reserved area of cache memory, called "shared memory," that is never deallocated, so that this information will always be found in the cache memory when a port adapter attempts to access it.

Referring to FIG. 8, there is shown a preferred construction for the persistent volume access table 88. The persistent volume access table 88 includes an entry for each distinct group of volumes to be accessible to a particular host controller from a particular port adapter. The persistent volume access table 88 has columns for volume group names, host controller WWNs, a private/shared flag, and pointers to volume lists, and these columns are similar to the corresponding columns in the table 82 of FIG. 5. The persistent volume access table 88 further includes columns for a volume bitmap and a port adapter index list. A volume bitmap has a respective bit for each logical volume in the storage subsystem, and the respective bit is set if the logical volume associated with the bit is included in the volume list, and not set if the logical volume associated with the bit is excluded from the volume list. The port adapter index list includes the table index of each corresponding entry in a transient volume access table. Therefore, the port adapter index list could include an index for each port adapter to which the host controller is currently logged into. It may be desirable, but not necessary, for the hosts to log out of the port adapters. This would ensure that the volume access tables more precisely reflect the current state of the data network, and prevent any misdirection of messages if a network failure would prevent a storage adapter from being notified of a state change that would cause any S_ID in the transient volume access table to be reassigned.

In the persistent table 88 of FIG. 8, the information in each volume bitmap is redundant with the information in each volume list. In this case, the volume list is the original form of the information as specified by the system administrator at configuration time. The volume bitmap is used for rapidly searching whether a specified volume is in the volume list, for example in response to a data access request from the host controller port to which the volume list is associated. The volume bitmap is generated automatically from the volume list when the volume list is entered or modified by the system administrator. The volume list is retained for viewing and revision by the system administrator. In a system with a limited number of logical volumes, the volume list could be quickly generated from the volume bitmask, and therefore there would be no need to retain the volume list it in memory or include the volume list in the volume access table.

Referring to FIG. 9, there is shown a preferred format for the transient volume access table 80. The table 80 includes an entry for each host controller port currently logged into the port adapter. The table 80 includes columns for the host controller S_ID, the private/shared flag for the volume list, the volume bitmap, and a persistent table index. The persistent table index in each entry of the transient volume access table 80 points to the entry in the persistent volume access table having the same private/shared flag and volume bitmap as the entry of the transient volume access table, and having a host controller WWN corresponding to the host controller S_ID in the entry of the transient volume access table.

Referring to FIG. 10, there is shown a preferred format for the table directory 93. The table directory includes, in each entry, a list of pairs of the S_ID and corresponding index to the transient volume access table for each SID having a certain modulus of the S_ID. The modulus each S_ID in the table directory corresponds to the index of the directory table entry containing the S_ID. For example, the modulus of the S_ID is a certain number of least significant bits of the S_ID, and in this case the number of entries in the table directory 93 is two raised to the number of the least significant bits.

To search the transient volume access table 80 for an entry having a specified host controller S_ID, an index is computed by masking off the least significant bits of the specified S_ID to obtain the corresponding modulus, and the modulus is used to index the table directory to find a list of S_IDs and corresponding indices that should include the specified S_ID if the specified S_ID is somewhere in the transient volume access table. The list in the entry indexed by the modulus is searched for the specified SID, and if it is found, then its corresponding index is the index to the transient volume access table entry containing the specified S_ID. If the specified SID is not found in the list in the entry indexed by the modulus, the specified S_ID does not appear in the S_ID column of the transient volume access table.

Since S_IDs are assigned to hosts controller ports sequentially when the host controller ports share a loop, the size of the table directory 93 can be determined based on reasonable constraints on the network geometry. For example, if the most complex network geometry connects a certain maximum number of loops to one or both of the two physical ports of the port adapter (for example, as described below with reference to FIG. 38), then the number of entries in the table directory can be chosen to be greater or equal to the maximum number of host controller ports on a single loop, and the number of pairs of S_IDs and corresponding transient table indices in each entry of the table directory can be set to the maximum number of loops that can be connected to each port through one switch. However, the number of possible S_IDs in each entry of the table directory 97 can be reduced still further if one assumes a particular kind of connection between each loop and each port adapter port. For example, if a single switch is used to connect loops to the port adapter (for example, as shown in FIG. 38), and all of the host controller ports are assigned S_IDs sequentially by this switch, then the number of entries in the table directory can be chosen to be the smallest power of two greater or equal to the maximum number of host controller ports linked to the port adapter ports, and there will be at most one S_ID and corresponding transient volume access table index in each entry of the table directory.

Referring to FIG. 11, there is shove a flowchart of a microcode routine executed by the microprocessor (76 in FIG. 4) of the port adapter (35 in FIG. 4) in response to a "Report LUNs" or access request by a host. In a first step 101, the microprocessor decodes the S_ID from the request. Then in step 102, the microprocessor searches the volume access table for an entry having the S_ID from the request. For example, this is done by indexing the table directory of FIG. 10 with a modulus of the S_ID from the request, searching the indexed entry of the table directory for the S_ID from the request, and if the S_ID from the request is found in the entry, then indexing the volume access table of FIG. 9 with the corresponding index in the entry of the table directory. If the S_ID of the request is not found in the volume access table, then execution branches to step 104 to report no LUNs or deny the access request, and the routine is finished.

If the S_ID of the request is found in the volume access table, then execution continues to step 105. In step 105, the volume bitmap or volume list is accessed. For the volume access table format of FIG. 9 the volume bitmap is accessed, and for the volume access table format of FIG. 5, the volume list is accessed In step 106, execution branches to step 107 for a "Report LUNs" request. In step 107, the port adapter reports to the host controller a storage LUN for each volume in the volume bitmap or volume list, and the routine is finished. For an access request, execution continues from step 106 to step 108. In step 108, execution branches to step 109 if the volume to access is not in the volume bitmap or volume list. For a bitmap, this can be done simply by addressing the bit corresponding to the logical volume specified by the host controller. In general, the volume list is searched by using a technique most suitable for quickly searching the volume list. In step 109, the port adapter denies the storage controller access to the logical volume, and the routine is finished.

If the volume to access is in the volume bitmap or list, then execution continues from step 108 to step 110. In step 110, the private/shared flag is inspected for the indexed entry of the volume access table. If the private/shared flag is set, then execution continues from step 110 to step 111. In step 111, the port adapter accesses the logical volume specified by the host controller, and the routine is finished. If the private/shared flag is not set, then execution branches from step 110 to step 112 to access the locking information the cache memory. If the private/shared flag is set, then access is permitted, and execution branches from step 113 to step 111 to access the volume. If the volume to access is public and is already locked in a fashion incompatible with the access requested by the host (e.g., the volume is already write locked and the host controller requests a read or a write access, or the volume is already read locked and the host controller requests a write access) then access is not presently permitted. The host controller's S_ID is placed on a wait list, in order to notify the host controller when the logical volume becomes available; execution branches from step 113 to step 114 to temporarily deny access to the volume, and the routine is finished. If the volume to access is public and is not locked or is locked in a fashion compatible with the requested access by the host controller (e.g., the volume is already read locked and the host controller requests a read access), then a lock is granted to the host controller, and execution branches from step 113 to step 111 to access the volume, and the routine is finished.

Referring to FIG. 12, there is shown a flowchart 120 of a microcode routine 120 executed by the microprocessor (76 in FIG. 4) of the port adapter (35 in FIG. 4) when converting the vector representation of FIG. 6 to a list of logical storage volume identifiers. This routine is used, for example, in step 106 to report the storage LUNs in a disk spread defined by an entry in the volume list. In a first step 121, an index (I) is set to the first volume number (BEGIN) for the disk spread. Next, in step 122, the value of the index I is inserted onto the list. Then in step 123, the value of the index is compared to the last volume number (END) of the disk spread. If the value of the index is greater or equal to the value of the last volume number (END), then the routine terminates. Otherwise, execution continues from step 123 to step 124. In step 124, the index (I) is incremented by the stride (S), and execution loops back to step 122.

Referring to FIG. 13, there is shown a flowchart 130 of a microcode routine executed by the microprocessor (76 in FIG. 4) of the port adapter (35 in FIG. 4) when determining whether or not a specified logical storage volume is included in a disk spread defined by the vector representation of FIG. 6. This routine is used, for example, in step 107 to determine whether or not the volume specified by a data access request is included in a disk spread defined by an entry of the volume list. In a first step 131, the volume index (I) is compared to the first logical volume number (BEGIN) of the disk spread.

If the volume index (I) is less than the first logical volume number, the execution returns indicating that the specified logical storage volume is not included in the disk spread. Otherwise, execution continues from step 131 to step 132. In step 132, the volume index (I) is compared to the last logical volume number (END) of the disk spread. If the volume index (I) is greater than the last logical volume number, then execution returns indicating that the specified logical storage volume is not included in the disk spread. Otherwise, execution continues from step 132 to step 133.

In step 133, the stride (S) is compared to one. If the stride (S) is equal to one, then execution returns indicating that the specified logical storage volume is not included in the disk spread. Otherwise, execution continues to step 134. In step 134, the difference is calculated between the index I and the first logical volume number (BEGIN) of the disk spread. Then a value REM is computed which is the modulus of the difference (DIF) and the stride (S). In particular, if the difference (DIF) is zero, then REM is zero. Otherwise, DIF is divided by S using an integer division procedure, and REM is the remainder of the division. If REM is zero, then execution returns indicating that the specified logical volume is in the disk spread, otherwise, execution returns indicating that the specified logical volume is not in the disk spread.

Referring to FIG. 14, there is shown a graphical display 140 of disk spreads in a two-dimensional volume space. For example, the logical volumes I0 to I12 are arranged as a four-by-four square matrix. The rows of the matrix correspond to respective disk spreads defined by the respective vectors V0=(0, 3, 1), V1=(4, 7, 1), V2=(8, 11, 1), and V3=(12, 15, 1). For each of these row vectors V0 to V3, the stride (S) is one. Also shown is a disk spread defined by a column vector V4=(2, 14, 4) having a stride (S) of four. In a multi-processor system, for example, the disk spreads represented by each of the row vectors V0, V1, V2, V3 could be assigned to a respective one of four host processors, and the disk spread represented by the column vector V4 could be assigned to a fifth host processor. In this case, none of the first four processors would share any of the volumes with any other of the first four processors, but each of the first four processors would share one volume with the fifth processor. In this fashion, a limited amount of information can be stored in the memory of a port adapter to define a rather large number of volumes having various shared and private relationships among a multiplicity of host processors.

Referring to FIG. 15, there is shown a graphical display of disk spreads in a three-dimensional volume space. The volume space includes 4,096 volumes, or 16 volumes along each of the x, y, and z axes. Shown in this volume space is a first disk spread defined by a vector V5=(0, 15, 1) having a stride (S) of one, a second disk spread defined by a vector (15, 255, 16) having a stride (S) of sixteen, and a third disk spread defined by a vector V7=(255, 4095, 256). By using such a three-dimensional graphical display, it is possible to show complicated private and shared relationships between the volumes accessible to a large number of host computers. For example, the service processor 93 in FIG. 4 could provide such a three-dimensional view on the display. The volumes associated with a particular group name could be displayed in a corresponding primary color, so that the private and sharing relationships for up to three selected group names or host controller ports could be displayed simultaneously. For example, in FIG. 15, the disk spread specified by the vector V5 could be associated with a first host processor and displayed in red, the disk spread specified by the vector V6 could be associated with a second host processor and displayed in blue, and the disk spread specified by the vector V7 could be associated with a third host processor and displayed in green. Therefore the shared volume 115 would be displayed in magenta, and the shared volume I255 would be displayed in cyan. Moreover, the service processor could be programmed to display a colored two-dimensional 16.times.16 square matrix of the logical volumes for any selected one of 16 planes parallel to the x, y, or z axes in the logical volume space. In addition to indicating the private and shared relationships of the volumes to the hosts, the two-dimensional displays could provide additional information in the display region of each volume, such as a numeral or graph indicating of the free storage space in each volume.

Referring to FIG. 16, there is shown a flowchart 160 of a microcode routine executed by the microprocessor (76 in FIG. 4) of the port adapter (35 in FIG. 4) for volume configuration when installing the storage subsystem into the data processing system of FIG. 1. In a first step 160, the system administrator enters a group name for a host to be permitted access through one or more port adapters. For example, the system administrator manually operates the keyboard 92 in FIG. 4 to enter the host name, host controller number(s), and port adapter number(s). The service processor 93 forwards this information to the port adapter(s) and the microprocessor(s) in the port adapter(s) allocate(s) a table entry for each host controller number and places the respective group name into each table entry. Then in step 162, the port adapter(s) automatically search the network for the S_ID and WWN of the host controller ports corresponding to the group names. For example, the port adapters poll the ports of the hosts, and the host controllers are programmed to respond to port adapters by returning their host names and controller numbers. If the polling is successful in returning the S_ID and WWVN associated with the group name, as tested in step 163, then execution continues to step 164. In step 164 the system administrator enters a volume list for the group name, for example by entering logical volume numbers, ranges of logical volume numbers, or vector specifications (beginning number, ending number, stride) at the keyboard 92 in FIG. 4. In step 165, the microprocessor creates a table entry for the group name and its associated S_ID, WWN, and a pointer to the volume list. In step 166, execution continues to step 167 if the system administrator has no more group names to enter; otherwise, execution loop back to step 161. In step 167, the volume access table and volume lists are copied to a storage volume as back-up for port adapter error recovery or diagnostic purposes, and the routine if finished. The back-up copy should be updated if additional group names are added to the volume access table or if the volume lists are changed

If the polling is not successful in returning a S_ID and WWN for a host or group name, then execution branches from step 163 to step 168. In step 168, the items not found are reported to the system administrator, who has the option of creating or not creating a table entry if the items cannot be found. For example, it is possible for the system administrator to permit a table entry to be created for host controllers that are not presently logged into the data network, and the port adapter can fill in the missing items automatically if and when the host controller are booted. If the system administrator has selected the option of not creating a table when items are missing, then execution branches from step 169 to step 166. Otherwise, execution continues from step 169 to step 170. In step 170, the S_ID and WWN for the group name is set to null, and then execution continues to step 164.

Referring to FIG. 17, there is shown a flowchart 180 of a microcode routine executed by the microprocessor (76 in FIG. 4) of the port adapter (35 in FIG. 4) when notified of a network state change such as a host controller boot. In a first step 181, the port adapter obtains the WWN, the S_ID, and the group name of the host controller port. Then in step 182, the volume access table is indexed Keith the group name. If no entry for the group name is found in the table, then the routine is finished. Otherwise, execution continues to step 183. In step 183, the WWN obtained from the host controller port is compared to the WWN in the table entry. If the WWN obtained from the host controller port is the same as the WWN in the table entry, then execution continues from step 183 to step 184. In step 184, the S_ID value in the table entry is reset to the value obtained by the port adapter in step 181, and the routine is finished.

If in step 183 the WWN obtained from the host controller port is different from the WWN in the table entry, then execution branches from step 183 to step 186. In step 186, execution branches to step 188 if the WWN in the table entry is null. The null value in the table indicates that the system administrator has authorized the WWN to be set during a controller boot, for example just after an authorized installation or change of a host controller circuit board. Therefore, in step 188 the WWN and S_ID obtained in step 181 are entered into the entry of the volume access table, and the routine is finished. In step 186, if the WWN entry is not null, then an unauthorized change in a host controller circuit board has occurred, and execution branches from step 186 to step 187 to report the error to the system administrator, and then the routine is finished.

Referring to FIG. 18, there is shown is a flowchart of the procedure that should be performed by a system administrator during host controller replacement. In step 201 the host is interrupted to suspend any communication over the data network or shut down to permit replacement of the host controller. Unless the host controller board has a "hot swap" capability, the host will be shut down to shut off power to the controller board before it is removed and replaced. Then in step 902, the system administrator nullifies the host controller's WWN in all such WWN entries in all volume access tables in all port adapters of the storage subsystem, and in step 203 the host controller is replaced. The replacement of the host controller board causes the WWNs of the ports of the host controller board to change. In step 204, host processing is restarted or continued, including a boot of the new host controller board, and the procedure is finished.

Mapping of LUNs to Logical Volume Numbers

As described above with reference to FIG. 7, a host may request access to a specified logical volume in the storage subsystem. If a host may access only a very limited set of the logical volumes in the data storage subsystem, however, it may be desirable for the port adapter to report back to each host a limited range of LUNs representing logical volumes that the host can access, and for the port adapter to map this limited range of LUNs to the limited set of logical volumes that each host can access. The host therefore does not need to deal with a large number of possible volumes, and minimal modification of the host programming is needed when a host is networked to the data storage subsystem. Instead of specifying a logical volume number when requesting access to a logical storage volume, the host specifies a LUN, and the port adapter receiving the storage access request translates the specified LUN to a corresponding logical volume number. There can be a different mapping of LUNs to logical volume numbers for each host or host controller port.

As shown in FIG. 19, the mapping of LUNs to logical volume numbers for a volume group name is specified by the entries in the volume list 210 associated with the volume group name. Each entry in the volume list 210 includes a LUN in the volume group and its corresponding logical volume number (VOL_NO.). The first entry 211 in the volume list, for example, maps LUN I to logical volume number 8.

In practice, it is desirable to assign ranges of contiguous LUNs to the volume groups or hosts. These ranges of contiguous LUNs, for example, are evident when the LUNs in the volume list are sorted by LUN, for example as shown in FIG. 19. In many cases, each range of contiguous LUNs corresponds to a range or vector of logical volume numbers. Therefore, in a data processing system having a large number of LUNs per host and an even larger number of logical volumes, it may be desirable to specify the LUN to logical mapping as a number of ranges of contiguous LUTNs and corresponding vectors of logical storage volume numbers.

As shown in FIG. 20, for example, each entry in the volume list 220 associates a respective range of contiguous LUNs with a vector of logical volume numbers. Each entry includes the first LUN in the range, the number (N) of LUNs in the range, the beginning logical volume number in the associated vector of logical volume numbers. and the stride (S) of the vector. The first entry 221 in the volume list 220, for example, specifies a first LUN of one, a number (N) of three, a beginning logical volume number of eight, and a stride (S) of two. This maps the sequence of contiguous LUNs (1, 2, 3) to the sequence of logical volume numbers (8, 10, 12), and therefore the first entry 221 in the volume list 220 of FIG. 6 encodes the same information as the first three entries in the volume list 210 of FIG. 19.

To find whether a specified LUN is within the map of any entry in the volume list 220, the specified LUN value is compared to the LUN value in the entry, and if it is less than the LUN value in the entry, the specified LUN is not within the map of the entry. If the specified LUN value is greater or equal to the LUN value of the entry, then the specified LUN value is compared to the LUN value in the entry plus the value of N in the entry. If the specified LUN value is less than the LUN value in the entry plus the value of N in the entry, then the specified LUN is within the map of the entry; otherwise, it is not. If the specified LUN is within the map of the entry, then its corresponding logical storage volume number is computed as:

LOGICAL_VOLUME_NO.=MAP_VOL_NO.+(SPEC_LUN-MAP_LUN)*S

where MAP_VOL_NO, is the VOL_NO in the map entry, SPEC_LUN is the specified LUN value, and MAP_LUN is the LUN value in the map entry.

Volume Partitioning by Virtual Ports

As described above with reference to FIG. 7, the port adapters can be programmed to provide a "Report LUNs" command that will report to each host only the LUNs or logical storage volumes assigned to the host. In other words, a host would not normally have the capability of seeing the LUNs or logical volumes assigned to another host. This offers some security, but it is incompatible with the conventional "Report LUNs" command of the Fibre Channel standards. In a Fibre Channel network, if a conventional "Report LUNs" command is used to discover LUNs, all ports will report back all of their LUNs.

The method of FIG. 7 also has the disadvantage that a significant amount of port adapter processing time is spent in managing variable-length volume lists or very long bitmaps. The method of FIG. 7 further has the disadvantage that the entire group of volumes for a host controller must be flagged as shared if only one of the volumes in the group are shared, which increases the access time of the private volumes in the group. It would be desirable to use a predefined, fixed-length format for the lists that are frequently accessed if this would not waste port adapter memory or unduly limit the set of logical volumes that could be assigned to each host. For a host controller having both shared and private volumes, it would be desirable to associate more than one group of volumes to the host controller, including one or more groups of all private volumes and one or more groups of all public volumes, so that each group can be separately flagged as private or public.

The method of virtual ports overcomes these disadvantages in a way that is compatible with the Fibre Channel specifications. In accordance with the method of virtual ports, the storage subsystem presents to the Fibre Channel network a set of "virtual" Fibre Channel ports that do not really exist on the network. A set of logical volumes is assigned to each of the virtual ports. The logical volumes within each set are accessible from the virtual port through at least one physical port of the storage subsystem. This physical port is therefore a fabric port and the storage subsystem provides a virtual switch from the physical port to each of the virtual ports accessible through the physical port. In particular, the physical port is a Fibre Channel FL_Port if it is in a loop of the Fibre Channel network, or it is a Fibre Channel E_Port if it is connected to a switch, or otherwise it is a Fibre Channel F_Port. The port adapter providing the physical port is programmed to function as an FL_Port, E_Port or F_Port by responding to host login commands and assigning S_IDs; by responding to conventional Fibre Channel Report LUNs commands for reporting LUNs assigned to the virtual ports; and by responding to routing instructions from a host for routing data access requests to a specified virtual port and a specified LUN of the virtual port.

When using the method of virtual ports for volume partitioning, one or more virtual ports are assigned by the system administrator to each of the hosts having access to one or more of the virtual ports. Preferably logical storage volumes can be accessed through a single virtual port by no more than one assigned host. This simplifies the access control or filtering function of the storage subsystem, and does not unduly restrict the sets of logical volumes that can be accessed since a sufficiently large number of virtual ports can be created. A fixed-length format can be used for storing the lists of hosts, virtual ports, and LUN to logical storage volume mapping information for each virtual port because a variable number of virtual ports can be assigned to each host. If a host needs more logical storage volumes than can be included in the volume list for a single virtual port, another virtual port can be created and assigned to the host. Moreover, each virtual port can be accessible through any desired number of the storage subsystem adapter ports defined as FL_Ports, E_Ports, or F_Ports. The virtual port is made accessible by storing in the memory of the port adapter the access and mapping information for the virtual port.

A host uses conventional Fibre Channel commands and protocols for sending requests to its assigned virtual port or ports. Since the Fibre Channel standards do not restrict the ability of a host to send requests to all of the ports linked by the Fibre Channel network, there must be a mechanism for the system administrator's assignment of the virtual ports to the hosts to be communicated to the hosts, and the hosts must use this information to direct their storage access requests to the virtual ports to which they are assigned. This assignment information must also be used by the host if the host has an operating system that permits the host to boot from a logical volume in storage linked by the Fibre Channel network to the host, or that permits the operating system of the host to collect information about the logical storage volumes that it can access. In other words. the operating system routine that searches for the storage volumes that are accessible to the host must send Report LUNs commands to only the virtual ports assigned to the host and not to the virtual ports assigned to other hosts.

With reference to FIG. 21, the port adapter 36 of the cached storage subsystem 20 is shown having been programmed to provide virtual ports for access to respective groups of logical storage volumes. The port adapter 36 has two physical ports 231 and 232 provided by port circuitry 233 and 234, respectively. The port circuitry performs serializing, framing, sequencing, flow control, and coordination of protocols and services in accordance with the Fibre Channel standards. The port adapter 36 further includes a microprocessor 235 and a random access memory 236. The microprocessor 235 executes microcode 237 in the random access memory 236. In particular, the microprocessor 235 is instructed by the microcode 236 to handle Fibre Channel requests received by the port circuitry 233 in such a way that there appears to be a respective switch 238, 239 in the storage controller 27 connecting each of the ports 123, 131 to a respective set of ports 240, 241 between the ports 123, 131 and the storage volumes (28, 29, 30, and 31) in the cached storage subsystem 20. Since the ports 240, 241 do not appear as physical nodes anywhere in the cached storage subsystem 20, the ports 240, 341 are called virtual ports, and the switches 238 and 239 are called virtual switches.

As far as the data network 291 is concerned, the virtual ports 240 and 241 function in a fashion similar to physical ports in the data network. The virtual ports are assigned respective port names. WWNs, and S_IDs, and requests from other nodes in the network are routed to them through their respective virtual switches 238, 239. For example, the virtual ports respond to Report LUN requests in a fashion similar to physical ports. In order to define the structure of the virtual switches, the random access memory 236 is programmed with switch definitions 242 and also stores switch state information 243. The switch definitions 242, for example, include the respective WWNs of the virtual switches 238 and 239, and the switch state 243 includes the S_IDs assigned at any given time to the virtual ports 240 and 241. The microcode 237 is also programmed to provide respective name servers 244 and 245 which provide nodes linked to the respective ports 231 and 232 with limited access to the switch definitions 242 and switch state 243. In particular, the name servers can provide the respective names, WWNs, and S_IDs of all the virtual and physical ports of the virtual switches.

The random access memory 236 is further programmed with volume access and mapping information 246. The volume access information indicates a respective set of storage LUNs that any host can access by requests addressed to the virtual ports 240, 241. The volume mapping information indicates respective logical volumes mapped to the virtual ports 240, 241. The volume access and mapping information for each of the virtual switches 238, 239 could be the same or it could be different. For example, it could be the same to permit any host to be disconnected from any one of the network loops 42, 44 and connected to the other loop without any change in the storage access privileges or procedures of the host. The set of logical storage volumes mapped to different virtual ports can be the same or different. For example, the set of logical storage volumes mapped to two virtual ports can be the same to permit two hosts to share the set of logical storage volumes mapped to the two virtual ports.

With reference to FIG. 22, there is shown a data processing system having a cached storage subsystem 250 and four host computers 251, 252, 253, 254 linked to the cached storage subsystem by a data network 255. In this example, the hosts are linked by four loops 256, 257, 258, 259 to respective network port adapters 260 and 261 of the cached data storage subsystem. Each port adapter has two physical ports designated as "A" or "B". The physical port 262 of the port adapter 260 is an "A" port linked to the loop 256, the physical port 263 of port adapter 260 is a B port linked to the loop 257, the physical port 264 of port adapter 261 is an "A" port linked to the loop 258, and the physical port 265 of port adapter 261 is a "B" port linked to the loop 259. The port adapters 260, 261 are programmed to provide respective virtual switches 266, 267 linking their "A" and "B" physical ports to a set of virtual ports 268, including a respective virtual port VP1, VP2, VP3, VP4 assigned to each of the hosts 251, 252, 253, 254. Each of the port adapters 260 and 261 is programmed with respective volume access information 269, 270 which can be identical to permit any of the hosts 251, 252, 253, 254 to be disconnected from any one of the loops 156, 157, 158, 158 and reconnected to any other of the loops without any change in the storage access privileges or procedures of the host.

With reference to FIG. 23, there is shown an example of the volume access and mapping information 269 of FIG. 18. The volume access and mapping information 246 of FIG. 21 can have a similar format. The volume access and mapping information 269 includes a virtual port host table 281 listing each host having access rights through a virtual switch controlled with the volume access and mapping information, and a virtual port mapping table 282 listing each virtual port accessible through the virtual switch controlled with the volume access and mapping information. Separate tables are used because each host listed in the host table can have more than one assigned virtual port. Also included in the volume access and mapping information 269 are optional lists 283 of indices to the virtual port identifiers in the virtual port mapping table 282 assigned to each host in the virtual port host table 281. The lists 283 are optional because the information in the lists could be obtained by scanning through an entire column of host indices in the virtual port mapping table. The lists 283 are not needed for handling a storage access request by a host. The lists 283 are used for quickly responding to a host when the host requests a report of the virtual ports from which it can access logical storage volumes. It is desirable to compile the lists by scanning the host index column of the virtual port mapping table and store the lists if a large number of hosts will be requesting the information frequently, for example, if the hosts login to the network frequently and request the information during each network login. The lists 283 in total have a limited memory requirement because each virtual port in the virtual port mapping table can have only one assigned host, so that in total the lists 283 include no more than one occurrence of a virtual port index for each of the virtual ports listed in the virtual port mapping table.

Referring to FIG. 24, there is shown a format for the virtual port host table 281. The table 282 includes a unique row for each host controller port from which a host can access a virtual port defined in the virtual port mapping table (282 of FIG. 23). The table 281 includes a column for the HOST_ID of the host controller port, a flag PORT A/B indicating whether the host controller port is linked to the physical "A" or "B" port of the port adapter programmed with the table 281, the WWN of the host controller port, the S_ID of the host controller port, a V_PORT INDEX which is a first index to a row of information in the virtual port mapping table (282 in FIG. 23) to which the host controller port has access through the port adapter, and a V_PORT LIST POINTER which is zero if there is only one V_PORT associated with the host controller port and otherwise points to a list of additional virtual port mapping table indices to rows of information about additional virtual ports to which the host controller has access through the port adapter.

The HOST_ID, for example, is the IP address of the host controller port. The HOST_ID could have the same format as the volume group name of the table in FIG. 5; i.e., a host name and controller sequence number

If the optional lists of indices to the virtual port table are not used, the V_PORT LIST POINTER would simply be a flag indicating whether or not there is more than one virtual port associated with the host controller port. If there is only one, it is found in the V_PORT INDEX column of the virtual port host table. If there is more than one, then the entire list can be found by scanning the HOST INDEX column of the virtual port mapping table 282 for entries having a HOST INDEX matching the index of the row in the virtual port host table containing the information for the host controller port.

Referring to FIG. 25, there is shown a format for the virtual port mapping table 282. The table 282 includes a unique row for each virtual port accessed through the port adapter. The table 282 includes a column for the V_PORT_ID of the virtual port, a HOST INDEX to a row of the virtual port host table for the host controller port associated with the virtual port, a private/shared flag, and a LUN TO LOGICAL VOLUME MAP specifying the set of LUNs at the virtual port, the set of logical storage volumes accessible from the virtual port, and the mapping between the LUNs and the logical storage volumes accessible from the virtual port. The V_PORT_ID is a primary key for the table 282. The table 282, for example, is sorted by the V_PORT_ID or has an associated hash table directory to facilitate searching of the table for a specified value of the V_PORT_ID. The VPORT_ID could be an IP address for the virtual port.

The LUN TO LOGICAL VOLUME MAP in each row of the table 282 could use the format of FIG. 19 or FIG. 20 with a fixed number of either the entries shown in FIG. 19 or the entries shown in FIG. 20. Since there would be a fixed number of possible entries of the format of FIG. 19 or FIG. 20 but less than all of the entries might be used at any given time, the unused entries could be filled in with a null value for the LUN, such as a zero LUN value. The first entry would always be used, and any other entries used would be contiguous with the first entry, so that all of the entries used could be found by scanning and testing the LUN value in the entry. Alternatively, the LUN TO LOGICAL VOLUME MAP for each virtual port could be preceded with an integer value indicating the number of entries used in the map at any given time.

The LUN TO LOGICAL VOLUME MAP in each row of the table 282 could be a bitmap in the form of a LUN to logical volume mapping matrix. The logical OR of all the rows of such a matrix would be a bitmap indicating all of the logical volumes accessible from the virtual port. The logical OR of all the columns of such a matrix would be a bitmap indicating all of the LUNs accessible from the virtual port. The use of such a mapping matrix would not be a practical alternative if there were a large number of virtual ports, hosts, possible LUNs, and logical volumes, since the number of bits of memory for storing such all of the mapping matrices would be the product o the number of virtual hosts, the number of possible LUNs, and the number of logical volumes.

Referring to FIG. 26, there is shown a flowchart of a routine executed by the microprocessor of the port adapter to provide a service for reporting the virtual ports accessible to a host controller port through the port adapter. This service could provide such a report when a host controller logs in to the data network, or when a host controller port requests the information from a name server of the virtual switch provided by the port adapter. In a first step 301, the microprocessor searches the virtual port host table for an entry including a specified HOST_ID. In step 302, execution branches to step 303 if a table entry is not found for the specified HOST_ID. In step 303, the port adapter reports that there are no V_PORTS accessible to the host through the port adapter, and the routine is finished.

In step 302, execution continues to step 304 if a table entry is found for the specified HOST_ID. In step 304, the port adapter reports that the V_PORT of the V_PORT index in the table entry is accessible to the host. In other words, the microprocessor reads the V_PORT INDEX from the row of the virtual port host table containing the specified HOST_ID, and then indexes the virtual port mapping table with the V_PORT INDEX to find the first V_PORT_ID associated with the HOST_ID. In step 305, the V_PORT LIST POINTER is compared to zero, and if it is zero, then the routine is finished. Otherwise, execution continues from step 305 to step 306.

In step 306, the V_PORT list pointer is used to access the list of additional indices to accessible V_PORTS in the virtual port mapping table. Finally, in step 307, the port adapter reports that the indexed V_PORTS are accessible to the host through the port adapter, and the routine is finished.

Referring to FIG. 27, there is shown a flowchart 320 of a routine executed by the microprocessor of a port adapter when the port adapter receives from a host controller port a volume access or Report LUNs request to a specified virtual port. To ensure compliance with the Fibre Channel standards, this Report LUNs request might be different from and in addition to the standard Report LUNs command. The Report LUNs request of FIG. 27 reports the storage LUNs accessible to a specified host controller port, in contrast to the standard Report LUNs command which could report all LUNs accessible from a virtual port including all storage LUNs accessible from the virtual port by any of the hosts. In response to a standard Report LUNs command directed to a virtual port, the port adapter would search the virtual port mapping table 282 of FIG. 25 for the V_PORT_ID specified by the Report LUNs command to find the table entry including the V_PORT_ID, and then report all of the LUNs included in the LUN TO LOGICAL VOLUME MAP in the table entry.

In a first step 321 of the flowchart 320, the microprocessor searches the virtual port mapping table for the entry of the virtual port specified by the host. If such a table entry is not found, then execution branches from step 322 to step 323. In step 323, the request is denied, and the routine is finished. If such a table entry is found, then execution continues from step 322 to step 324. In step 324, the microprocessor obtains the HOST_INDEX of the entry of the virtual port mapping table. In step 325, the virtual port host table is indexed with the HOST_INDEX.

In step 326, the HOST_ID of the host controller port requesting access is compared to the HOST_ID in the indexed entry of the virtual port host table. If the HOST_ID of the host controller port requesting access is not equal to the HOST_ID in the indexed entry of the virtual port host table, then execution branches from step 326 to step 323. In step 323 the port adapter denies the request, and the routine is finished. If the HOST_ID of the host controller port requesting access is equal to the HOST_ID in the indexed entry of the virtual port host table, then execution continues from step 326 to step 327.

In step 327, the microprocessor checks whether the port adapter's physical port "A" or "B" from which the request was received is the same as the physical port "A" or "B" indicated by the PORT A/B flag in the indexed entry of the virtual port host table. If not, then execution branches from step 327 to step 328. In step 328, execution branches from step 328 to step 323 to deny the request if a "fixed port option" is selected. The "fixed port option" would be selected if it is desired for a host controller port to access the specified virtual port only through a specified one of the physical "A" or "B" ports of the port adapter. This option could apply or not apply to all of the host controller ports, or the option could be specified by a flag (not shown) in each entry of the virtual port host table to selectively apply the option to each host controller port. For example, the option could be selected for desktop workstations, and not be selected for portable host computers. If the fixed port option is not selected, then execution continues from step 328 to step 329. In step 329, the microprocessor switches the PORT A/B flag in the table entry. Execution continues from step 329 to step 330 of FIG. 27. Execution also continues from step 327 to step 330 of FIG. 27 if the request was received from the port adapter's physical "A" or "B" port indicated by the PORT A/B flag in the indexed entry of the virtual port host table.

Referring to FIG. 28, in step 330 the S_ID from the request is compared to the S_ID in the indexed entry of the virtual port host table. If the S_ID of the request does not match the S_ID in the indexed entry, then execution branches from step 330 to step 331 to recover from the unreported state change. If the port adapter cannot verify the new S_ID in the request, then the request is denied; otherwise, the S_ID value in the indexed entry is changed to the new value in the request, and execution continues in step 332. Execution also continues from step 330 to step 332 if the S_ID from the request matches the S_ID in the indexed entry.

In step 332 execution branches to step 333 for processing a "Report LUNs" request from a host controller port. In step 333, the port adapter reports to the host controller port the LUNs in the LUN TO LOGICAL VOLUME MAP of the indexed entry of the virtual port mapping table, and the routine is finished. Execution branches from step 332 to step 334 for processing a storage access request from a host controller port. In step 334, the microprocessor searches the LUN TO LOGICAL VOLUME MAP of the indexed entry of the virtual port mapping table for the specified LUN to access. If the LUN to access is not found, then execution branches from step 335 to step 336. In step 336, the port adapter reports to the host controller port that the specified LUN to access is unknown, and the routine is finished.

Execution continues from step 335 to step 337 if the LUN to access is found in the LUN TO LOGICAL VOLUME MAP of the indexed entry of the virtual port mapping table. In step 337, the private/shared flag is inspected for the indexed entry of the volume access table. If the private/shared flag is set, then execution continues from step 337 to step 338. In step 338, the port adapter accesses the logical volume mapped to the LUN specified by the host controller, and the routine is finished. If the private/shared flag is not set, then execution branches from step 337 to step 339 to access locking information in the cache memory for the logical volume mapped to the LUN specified by the host controller. If the volume is private to the host controller, then access is permitted, and execution branches from step 340 to step 348 to access the volume. If the volume to access is public and is already locked in a fashion incompatible with the access requested by the host (e.g., the volume is already write locked and the host controller requests a read or a write access, or the volume is already read locked and the host controller requests a write access) then access not presently permitted. The host controller's S_ID is placed on a wait list, in order to notify the host controller when the logical volume becomes available; execution branches from step 340 to step 341 to temporarily deny access to the volume, and the routine is finished. If the volume to access is public and is not locked or is locked in a fashion compatible with the requested access by the host controller (e.g., the volume is already read locked and the host controller requests a read access), then a lock is granted to the host controller, and execution branches from step 340 to step 338 to access the volume, and the routine is finished.

GRAPHICAL USER IINTERFACE for VIRTUAL PORTS

A conventional graphical user interface (GUI) for a cached storage subsystem of the type shown in FIG. 1 includes a grid of logical volumes to storage adapter ports. At each intersection of the grid, the target/LUN is assigned. This provides a mechanism for the system administrator to set and view the mapping of LUNs to logical storage volumes and the storage adapter ports used for accessing the physical storage volumes that make up the logical storage volumes. Referring to FIG. 29, there is shown an example of how the mapping of LUNs to logical storage volumes can be incorporated into a GUI for a cached storage subsystem that uses virtual ports. It is still possible to use a grid for defining the relationship between logical volumes, LUNs, and storage adapter ports, but the GUI display screen is partitioned into groups of V_PORTs by physical port of the port adapters. In this example, each intersection allows the definition of the LUN only. FIG. 29, for example, shows a single grid 345 for the logical volumes accessible by a host controller port linked to the physical port A of a port adapter 1 addressing LUNs at a virtual port 1. A similar grid could be displayed for each virtual port defined in the storage subsystem.

Referring to FIG. 30, there is shown a GUI display screen for permitting the system administrator to set up the relationship between logical storage volumes of the storage subsystem (the volume source) and the volumes addressed by a host (the volume user). In this example, the GUI display screen includes, on the left, a list 346 in outline form of storage subsystem components down to a set of logical volumes for one virtual port, and on the right, a list 347 in outline form of host components down to a set of LUNs as addressed from one host controller port. The "bus" in the right column refers to a host controller, and the "target" in the right column refers to a port of the host controller. The display starts out with a list of storage subsystems and a list of hosts linked by the data network. The system administrator selects a storage subsystem or host by clicking on it with a pointing device such as a mouse interfaced to the service processor, and expand the list to the next lower level by double clicking on a selected item of the list. By expanding the lists down to the port adapter and host controller port levels, the system administrator clicks on a particular physical adapter port in the left column to get to virtual ports and logical volumes for the particular adapter port, and then clicks on a particular controller bus and target to get the LUNs as addressed by the host. The system administrator selects an unallocated virtual port in the left column for a physical adapter port and then selects a host controller port in the right column to allocate the host controller port to the virtual port. The system administrator could then select a logical storage volume, or selected range of volumes, and select a LUN or range of LUNs as addressed by the host controller port, to establish the LUN to logical volume mapping. For example, in FIG. 30, the GUI display has drawn a line 348 between the selected logical storage volume VOL I and the selected LUN 2 to show that such a mapping has been established. The system administrator could also select an item on either list and "collapse" the list to go back up to the level in the outline above the selected item. For data security, any unallocated logical volume should be reformatted or erased of any pre-existing data before being allocated.

The system administrator could select an item on either list and select a "properties" option to display properties of the selected item. For example, the grid 345 of FIG. 29 could be one of the properties of the virtual port 1. The properties of a logical storage volume would include the host controller ports having access to the logical storage volume, and the paths or adapter ports and virtual port through which the host controller ports can access the logical storage volume.

The preferred embodiment of the graphical user interface used by the system administrator has the following additional functions. For security, password protection is desirable on a user and/or host level. For flexibility, it is desirable to have be able to modify or view a host's volume configuration from local or remote hosts. The systems administrator should have the ability to read and write the physical and virtual port names of storage subsystem as defined in the a configuration database. The configuration database should contain flags that indicate if a volume can be shared. If sharing of a volume is forbidden, the graphical user interface does not allow it to be allocated to more than one host. If it can be shared, the system administrator is notified of this upon configuration creations of shared volumes.

The graphical user interface may recognize an "Install" command to be use when a new host controller port is introduced. The install command writes the host's configuration information into the volume configuration database.

The graphical user interface may recognize a "Repl